Разработка БД "Колледж"

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 25.04.2012
Размер файла 2,5 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://allbest.ru/

Содержание

Введение

Глава 1. Модели жизненного цикла АИС

1.1 Каскадная модель

1.2 V-образная модель

1.3 Модель прототипирования

1.4 Модель быстрой разработки приложений (RAD-модель)

1.5 Многопроходная модель

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

Глава 2 . Разработка базы данных «Колледж»

Заключение

Список использованной литературы

Введение

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

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

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

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

Данная курсовая работа создавалась с целью разработки БД «Колледж».

1. Модели жизненного цикла автоматизированных информационных систем

1.1 Каскадная модель

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

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

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

1.2 V-образная модель

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

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

Данная модель основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление требований. Проектирование разделяется на высокоуровневое и детальное (низкоуровневое). Разработка включает в себя кодирование, обзор - различные виды тестирования.

На модели хорошо просматриваются взаимосвязи между аналитическими фазами и фазами проектирования, которые предшествуют кодированию и тестированию. Штриховые стрелки показывают, что эти фазы надо рассматривать параллельно.

Модель включает в себя следующие фазы:

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

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

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

Детальное проектирование - определяется алгоритм работы каждого компонента;

Кодирование - выполняется преобразование алгоритмов в готовое программное обеспечение;

Модульное тестирование - выполняется проверка каждого компонента или модуля программного продукта;

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

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

Рис.1 V-образная модель

Преимущества v-образной модели:

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

2) Предполагаются аттестация и верификация не только самого программного продукта, но и всех полученных внутренних и внешних данных;

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

Кроме перечисленных достоинств модель обладает и рядом недостатков:

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

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

1.3 Модель прототипирования

Рис.2 Модель прототипирования

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

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

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

Модель протипирования обладает целым рядом преимуществ:

1) Взаимодействие заказчика с разрабатываемой системой начинается на раннем этапе;

2) Благодаря реакции заказчика на прототип сводится к минимуму число неточностей в требованиях;

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

4) В процессе разработки всегда можно учесть новые, даже неожиданные требования заказчика;

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

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

7) Заказчик всегда видит прогресс в процессе разработки программного продукта;

8) Возможность возникновения противоречий между разработчиками и заказчиками сведена к минимуму;

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

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

1) Решение сложных задач может отодвигаться на будущее;

2) Заказчик может предпочесть получить прототип, а не законченную полную версию программного продукта;

3) Прототипирование может неоправданно затянуться;

4) Перед началом работы неизвестно, сколько итераций придется выполнить.

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

1) Требования к программному продукту заранее неизвестны;

2) Требования не постоянны или неудачно сформулированы;

3) Требования необходимо уточнить;

4) Нужна проверка концепции;

5) Существует потребность в пользовательском интерфейсе;

6) Выполняется новая, не имеющая аналогов разработка;

7) Разработчики не уверены в том, какое решение следует выбрать.

1.4 Модель быстрой разработки приложений (RAD-модель)

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

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

На рисунке (рис.7), поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.

Модель включает в себя следующие фазы:

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

Описание пользователя - проектирование программного продукта, выполняемое при непосредственном участии заказчика;

Создание - детальное проектирование, кодирование и тестирование программного продукта, а также поставка его заказчику;

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

Модель обладает следующими достоинствами:

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

2) Привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым программным продуктом;

3) Повторно используются компоненты уже существующих программ.

В то же время ей присущи и недостатки:

1) Если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на программном продукте;

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

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

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

Рис.3 Модель быстрой разработки приложений

1.5 Многопроходная модель

Многопроходная модель (рис.8) - это несколько итераций процесса построения прототипа программного продукта с добавлением на каждой следующей итерации новых функциональных возможностей или повышением эффективности программного продукта.

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

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

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

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

Рис.4 Многопроходная модель

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

Рис.5 Спиральная модель

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

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

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

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

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

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

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

Рис.6 Улучшенная спиральная модель с указанием вспомогательных процессов

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

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

2. Разработка базы данных «Колледж»

Описание Microsoft Access

Базой данных Access является файл, который имеет расширение mdb. Этот файл может содержать не только все таблицы, но и другие объекты приложений Access -- запросы, формы, отчеты, страницы доступа к данным, макросы_и_модули.

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

При запуске Access появляется главное окно Microsoft Access. 

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

Если такой список в меню Файл (File) отсутствует, нужно с помощью команды Сервис, Параметры (Tools, Options) открыть диалоговое окно Параметры (Options), раскрыть вкладку Общие (General) и установить флажок Помнить список файлов (Recently used file list). Выбрать файл из списка в области задач, которая расположена в правой части окна приложения. Выбрать команду Открыть (Open) в меню Файл (File), и затем выбрать нужный файл в диалоговом окно Открытие файла базы данных (Open).

Особым окном в Access является окно базы данных, которое позволяет получить доступ ко всем объектам базы данных и выбрать режим работы с объектом. В левой части окна находится панель объектов, которая содержит ярлыки для каждого из объектов Access: Таблицы (Tables), Запросы (Queries), Формы (Forms), Отчеты (Reports), Страницы (Pages), Макросы (Macros), Модули_(Modules). 

Щелкнув на ярлыке мышью, в правой части окна вы откроете список соответствующих объектов. Список объектов может быть представлен четырьмя разными способами (обычными для папок операционной системы Windows):

- в виде мелких значков; 

- в виде крупных значков; 

- в виде списка; 

- в виде таблицы. 

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

С каждым объектом базы данных можно работать в двух режимах. Первый режим назовем режимом выполнения (условно, т. к. он несколько различается для разных типов объектов):

- для таблиц, запросов, форм и страниц доступа к данным этот режим означает открытие соответствующего объекта и называется, соответственно, режим Таблицы (для таблиц и запросов), режим

Формы, режим Страницы; 

- для отчета -- это режим предварительного просмотра; 

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

- для модуля этот режим отключен. 

Второй режим -- это режим Конструктора. Данный режим применяется ко всем типам объектов и предназначен для создания и изменения объектов. 

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

Чтобы посмотреть свойства объекта, необходимо проделать одну из следующих операций: щелкнуть правой кнопкой мыши на имени объекта и из контекстного меню выбрать команду Свойства (Properties); выделить объект из списка в окне базы данных и выбрать команду Вид, Свойства (View, Properties) из главного меню Access. 

Атрибуты (Attributes): Скрытый (Hidden) -- позволяет скрыть таблицу из окна базы данных, Реплицируемый (Replicated) -- позволяет управлять реплицируемостью_объекта.

Пользователь может изменять в окне свойств только описание таблицы и значения_ее_атрибутов. [8]

2.1 Работа с таблицами

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

В новой версии Microsoft Access существуют четыре режима работы с таблицами: режим Таблицы (Datasheet View), режим Конструктора (Design View), режим Сводной таблицы (PivotTable View) и режим Сводной диаграммы_(PivotChart_View).

В режиме Таблицы осуществляется работа с данными, находящимися в таблице: просмотр, редактирование, добавление, сортировка и т. п.

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

В режимах Сводной таблицы и Сводной диаграммы удобно выполнять анализ данных, динамически изменяя способы их представления. Существует также дополнительный режим -- режим Предварительного просмотра, который позволяет увидеть расположение данных на листе перед осуществлением печати таблицы. Для быстрого перехода из одного режима в другой служит кнопка Вид (View) на панелях инструментов Таблица в режиме таблицы (Table Datasheet), Конструктор таблиц (Table Design), Сводная таблица (PivotTable) и Сводная диаграмма (PivotChart). Чтобы перейти из режима в режим, достаточно нажать эту кнопку.

Открыть таблицу в режиме Таблицы можно несколькими способами: 

- дважды щелкнуть мышью на имени таблицы в списке таблиц в окне базы данных; 

- выделить таблицу в списке таблиц в окне базы данных и нажать кнопку Открыть (Open) в верхней части окна базы данных; 

- щелкнуть правой кнопкой мыши на имени таблицы и из контекстного меню выбрать команду Открыть (Open). [8]

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

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

Рис. 1.1. Создание таблицы в режиме конструктора

Рис.1.2. Таблица Преподаватели

2.2 Создание и печать отчетов

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

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

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

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

Чтобы создать автоотчет: 

- На панели объектов окна База данных (Database) щелкните по ярлыку Отчеты (Reports) и нажмите кнопку Создать (New). Появится диалоговое окно Новый отчет (New Report. 

- В списке диалогового окна Новый отчет (New Report) выделите один из элементов: Автоотчет: в столбец (AutoReport: Columnar) или Автоотчет: ленточный (AutoReport: Tabular). 

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

- Нажмите кнопку ОК. 

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

Чтобы созданный отчет можно было использовать в дальнейшем, его необходимо сохранить. Для этого выберите команду Файл, Сохранить (File, Save) или нажмите кнопку Сохранить (Save) на панели инструментов. Затем, в текстовое поле появившегося диалогового окна Сохранение (Save As) введите название нового отчета (например: Мой отчет) и нажмите кнопку ОК.[9]

Есть еще один вариант сохранения отчета: с помощью команды меню Файл, Сохранить как (File, Save As). Этой командой отображается диалоговое окно Сохранение (Save As) . Введите имя отчета и, прежде чем нажать кнопку ОК, убедитесь, что в раскрывающемся списке Как (As) этого окна выбран элемент Отчет (Report). Выбранный элемент определяет то, как будет сохранен новый отчет, точнее, в виде какого объекта базы данных Access. Дело в том, что в новой версии Access 2002 появилась возможность сохранить отчет в виде другого объекта базы данных -- страницы доступа к данным. Сделать это позволяет другой элемент раскрывающегося списка. Как -- элемент Страница доступа к данным (Data Access Page).

Рис. 1.4. Пример построения отчета

2.3 Описание форм

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

Это главная кнопочная форма.

При нажатии на кнопки «Студенты», «Преподаватели» и «Студенты» открываются отдельные формы , отчеты и запросы в которых возможно Нахождение, Добавление, Сохранение и Удаления записи.

При нажатии на кнопку «Предметы студента» выводятся данные предметах, которые изучает каждый студент

В форме «Студенты» предоставлены данные о Всех студентах колледжа

При нажатии на кнопку «Зав.отделения» выходит отчет о заведующих всех отделений.

жизненный цикл автоматизированный информационный

Схема данных.

Заключение

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

Работа состоит из двух глав.

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

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

Во второй главе мной описывается разработка базы данных «Колледж» с помощью MS Access. База данных была разработана на основе каскадной модели.

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

Список использованной литературы

1.Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000. - 352с.

2. Канер С., Фолк Д., Кен Нгуен Е. Тестирование программного обеспечения: Пер. с англ. - Киев: ДиаСофт, 2000. - 544с.

3. Соммервилл И. Инженерия программного обеспечения. - М.: СПБ.: Киев: Изд. дом «Вильямс», 2002. - 624с.

4. Ридман А.Л. Основы объектно-ориентированной разработки программных систем. - М.: Финансы и статистика, 2000. - 200с.

5. Гагарина Л.Г. Основы технологии и разработки программных продуктов: Учебник - М ФОРУМ - ИНФРА - М. 2006.

6. Семенов М.И. Трубилин И.Т., Лойко В.И. Барановская Т.П. Архитектура компьютерных систем и сетей Учебное пособие - М Финансы и статистика, 2004. - 320с.

7. Советов Б.Я. Цеханковский В.В. Информационные технологии - М Высшая школа, 2003.

8. Информатика: Учебник под редакцией Макаровой Н.В. - М.:Финансы и статистика., 2005. - 480с.

Размещено на Allbest.ru


Подобные документы

  • Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.

    курсовая работа [1,8 M], добавлен 20.11.2010

  • Анализ проблем, решаемых при помощи итерации. Изучение жизненного цикла разработки информационных систем и автоматизации. Дисциплины жизненного цикла IBM Rational Unified Process. Особенности внедрения процессов и инструментальных средств в организации.

    реферат [751,0 K], добавлен 05.10.2012

  • Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.

    презентация [874,4 K], добавлен 19.09.2016

  • Методология структурного анализа и проектирования информационных систем. Базовый стандарт процессов жизненного цикла программного обеспечения. Цели и принципы формирования профилей информационных систем. Разработка идеальной модели бизнес-процессов.

    презентация [152,1 K], добавлен 07.12.2013

  • Основные методологии проектирования, модели жизненного цикла локальных систем, сущность структурного подхода. Моделирование потоков процессов и программные средства поддержки их жизненного цикла. Характеристика и технология внедрения CASE средств.

    курсовая работа [686,9 K], добавлен 13.12.2010

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

    презентация [159,1 K], добавлен 27.12.2013

  • Жизненный цикл автоматизированных информационных систем. Основы методологии проектирования автоматизированных систем на основе CASE-технологий. Фаза анализа и планирования, построения и внедрения автоматизированной системы. Каскадная и спиральная модель.

    курсовая работа [1,1 M], добавлен 20.11.2010

  • Стадии жизненного цикла ИС и его стандарты. Методологии, поддерживающие спиральную модель. Каскадная и инкрементная модели, их достоинства и недостатки. Основные, вспомогательные и организационные процессы жизненного цикла. Сравнительный анализ моделей.

    курсовая работа [186,4 K], добавлен 21.05.2015

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

    презентация [350,6 K], добавлен 09.11.2015

  • Исследование основных стадий жизненного цикла информационной системы. Планирование, анализ требований и проектирование информационной системы. Стандарты и типы моделей жизненного цикла. Верификация и модернизация системы, полное изъятие из эксплуатации.

    презентация [1,6 M], добавлен 12.02.2017

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.