Этапы жизненного цикла информационной системы

Рис.1. Структурная схема процессов жизненного цикла

   Основными моделями жизненного цикла являютcя: классическая (каскадная, водопадная), модель с промежуточным контролем и спиральная.

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

Достоинствами такой схемы являются:

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

• простота планирования процесса разработки.

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

Рис.2. Каскадная схема разработки программного обеспечения

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

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

• изменение требований заказчика непосредственно в процессе разработки;

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

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

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

Модель с промежуточным контролем.

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

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

Рис.3. Схема разработки программного обеспечения с промежуточным контролем

Спиральная модель. Для преодоления перечисленных проблем в середине 80-х годов XX века, была предложена спиральная схема. В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов. Именно появление прототипирования привело к тому, что процесс модификации программного обеспечения перестал восприниматься, как «необходимое зло», а стал восприниматься как отдельный важный процесс.

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

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

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

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

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

Рис.4. Спиральная или итерационная схема разработки программного обеспечения.

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

использования продукта;

• уменьшить вероятность морального устаревания системы за время разработки.

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

В данном курсовом проекте моделируемая предметная область (друзья/подружки), в качестве модели ЖЦ ИС выбрана классическая (каскадная) модель. Т.к. на практике такие разработки встречается крайне редко (пользователь может, получит морально устаревший продукт), а при разработке простых программных продуктов классическая модель, где сразу было бы точно определено, что нужно заказчику и не было бы уточнений требований с его стороны в процессе выполнения программного продукта, является наиболее приемлемой. Именно в нашем случае проектируемая информационная система не затрагивает недостатков классической модели. Также классическая модель жизненного цикла не так уж категорична в отношении смены требований заказчика, если они не затрагивают требований изложенных при заказе информационной системы. Например, до получения конечного продукта, после выполнения стадии проектирования (контрольная точка проверки спецификаций) заказчик может потребовать изменить интерфейс, данное изменение не затрагивает требований, изложенных первоначально.

Этапы жизненного цикла информационной системы

Классическая (каскадная) модель жизненного цикла информационной системы (друзья/подружки) состоит из этапов:

• Постановка задачи
• Анализ требований и определение спецификаций
• Проектирование
• Реализация
• Внедрение
• Сопровождение

Постановка задачи

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

Относительно разрабатываемой ИС можно выдвинуть следующие функциональные требования:

· Обеспечить ввод/вывод данных о друзьях/подружках

· Реализовать механизм каталогизации по группам

· Реализовать механизм поиска контактной информации на основе запроса

Анализ требований и определение спецификаций

Спецификацияминазывают точное формализованное описание функций и ограничений разрабатываемого программного обеспечения. Соответственно различают функциональные и эксплуатационныеспецификации.

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

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

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

В данном курсовом проекте представлены два этапа:

       - анализ поведения системы:

- определяется назначение ИС;

       - анализ данных:

- определение состава потока данных

- конструирование глобальной модели данных в виде ER-диаграммы.

Проектирование

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

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

• декомпозицию компонентов и построение структурных иерархий в соответствии с

рекомендациями блочно-иерархического подхода;

• проектирование компонентов.

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

Принято различать также два аспекта проектирования:

• логическое проектирование, которое включает те проектные операции, которые

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

• физическое проектирование - привязка к конкретным техническим и программным

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

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

Реализация

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

В данном проекте представлены следующие пункты:

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

Внедрение

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

Сопровождение

Сопровождение - это процесс создания и внедрения новых версий программного продукта. Причинами выпуска новых версий могут служить:

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

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

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

На этом этапе в программный продукт вносят необходимые изменения, которые так же, как в остальных случаях, могут потребовать пересмотра проектных решений, принятых на любом предыдущем этапе. С изменением модели жизненного цикла программного обеспечения роль этого этапа существенно возросла, так как продукты теперь создаются итерационно: сначала выпускается сравнительно простая версия, затем следующая с большими возможностями, затем следующая и т. д. Именно это и послужило причиной выделения этапа сопровождения в отдельный процесс жизненного цикла в соответствии с стандартом 1SO/IEC 12207.

Выбор CASE-средства

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

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

· оценка нескольких CASE-средств и выбор одного или более из них;

· оценка одного или более CASE-средств и сохранение результатов для последующего использования;

· выбор одного или более CASE-средств с использованием результатов предыдущих оценок.

Рис. 5. Модель процесса оценки и выбора

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

· определение пользовательских потребностей;

· цели и ограничения проекта;

· данные о доступных CASE-средствах;

· список критериев, используемых в процессе оценки.

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

Элементы процесса включают:

· цели, предположения и ограничения, которые могут уточняться в ходе процесса;

· потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам;

· критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;

· формализованные результаты оценок одного или более средств;

· рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).

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

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

Определение списка критериев основано на пользовательских требованиях и включает:

· выбор критериев для использования из приведенного далее перечня;

· определение дополнительных критериев;

· определение области использования каждого критерия (оценка, выбор или оба процесса);

· определение одной или более метрик для каждого критерия оценки;

· назначение веса каждому критерию при выборе.

В данном курсовом проекте в качестве методологий проектирования выбраны методологии структурного анализа и проектирования, основанные на моделировании потоков данных. Для представления проектируемой ИС используется модель - диаграмма «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающая базы данных разрабатываемой системы.

Все CASE средства для моделирования можно классифицировать по назначению на две группы:

       1. Средства для создания модульной структуры системы

       2. Средства для создания модели данных системы

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

Семейство ERwin компании Logic Works (США) относится к мощным персональным CASE-продуктам, предназначенным для моделирования баз данных различного типа.

ERwin является популярным пакетом среди профессиональных разработчиков благодаря полной поддержке широкого спектра СУБД разного класса, включая SQLBase, DB2, Oracle, CA Ingres, MS SQL Server, Sybase, Informix, Rdb, Watcom, AS/400, Progress, Clipper, dBase, Access, Fox, Paradox.

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

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

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

Одно из достоинств системы ERwin состоит в том, что, построив один раз полноценную модель базы данных, вы можете легко ее развивать, модифицировать и переносить с одного сервера базы данных на другой. Используя стандарт IDEF1X, разработанный военно-воздушными силами США, ERwin позволяет создавать сложные документы в простом для понимания виде. ERwin не только дает возможность создать логическую модель, он также автоматически строит физические структуры данных по информации в построенной диаграмме. Нет необходимости тратить время на разработку сценариев для создания базы. ERwin полностью поддерживает возможности FRE (forward and reverse engineering) с использованием каталогов целевого сервера.

Стандарт IDEF1X регламентирует разработку структуры базы данных с нуля — прямое моделирование. Под прямым моделированием понимается возможность описывать схему базы данных в графическом виде, а затем получать сценарий на языке SOL или готовую базу данных. При прямом моделировании используются базовые для реляционной модели данных понятия «сущности» и «связи». Сами диаграммы соответственно так и называются — диаграммы «сущность—связь». Все данные достоинства и позволили сделать выбор в пользу ERwin.

Описание программы

Данный программный продукт позволяет хранить, изменять, удалять и просматривать информацию о друзьях/подружках пользователя информационной системы. Это осуществляется путем работы с базой данных «Друзья/Подружки» и реализует следующие функции: вывод информации на экран, фильтрация данных путем выполнения SQL запросов, добавление данных в справочник, удаление данных из справочника, редактирование ранее внесенных данных. Программа “Друзья/подружки” написана на языке программирования Delphi в среде визуального программирования: Borland Delphi 7.0.

Конфигурация компьютера, на котором производилась разработка программы:

       Процессор: Intel® Pentium® D CPU 3.40ГГц

Оперативная память: 2048 МБ

Видеокарта: NVIDIA GeForce 7600 GT

Жесткий диск: 320 Gb Western Digital 7200rpm, 16Mb Cache, SATA II

Необходимое программное обеспечение: Операционная система Windows 98/ME/2000/XP.

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

Рис. 6. Главное окно программы.

Заключение

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

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

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

1. Фаронов В., Программирование баз данных в Delphi 7. Учебный курс. – Спб.: Питер, 2005. – 459с.: ил.

2. Понамарев В., Базы данных в Delphi 7. Самоучитель. – СПб.: Питер, 2003. – 224 с.: ил.

3. Венчковский Л.Б. Разработка сложных программных изделий: Учеб. пособие для вузов — М.: ЗАО «Фин-статинформ», 1999.

4. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем.

ПРИЛОЖЕНИЕ 1

Нормальные формы

                         Рис. 7. Третья нормальная форма.

ПРИЛОЖЕНИЕ 2

Руководство пользователя

Для запуска программы необходимо открыть файл Project 1.exe. После загрузки программы на экране монитора появится главное окно. В этом окне можно просматривать информацию о друзьях/подружках пользователя. Первоначально активирована кнопка “Просмотр”, где можно просматривать: идентификационный номер, фамилия, имя, отчество, адрес, работа, зодиак, телефон. Также в случае смены номера телефона, можно добавить новый телефон и удалить старый.

Рис. 8. Главное окно программы.

При нажатии кнопки “Добавление” открывается окно, где необходимо ввести: фамилию, имя, отчество, а также выбрать из списка: адрес, работа, зодиак, телефон.

Рис. 9. Окно “Добавление”
                                                                                                                        ПРИЛОЖЕНИЕ 3

Листинг программы

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, ExtCtrls, ComCtrls, DB, ADODB, DBCtrls, Grids, DBGrids;

type

TForm1 = class(TForm)

ADOConnection1: TADOConnection;

ADODataSet1: TADODataSet;

PageControl1: TPageControl;

TabSheet1: TTabSheet;

TabSheet2: TTabSheet;

Label1: TLabel;

ComboBox1: TComboBox;

Label2: TLabel;

Edit1: TEdit;

Label3: TLabel;

Edit2: TEdit;

Label4: TLabel;

Edit3: TEdit;

Label5: TLabel;

Edit4: TEdit;

Label6: TLabel;

ComboBox2: TComboBox;

Label7: TLabel;

 Label8: TLabel;

Edit6: TEdit;

Label9: TLabel;

Edit7: TEdit;

ComboBox3: TComboBox;

Bevel1: TBevel;

Button1: TButton;

DBGrid1: TDBGrid;

DBNavigator1: TDBNavigator;

DataSource1: TDataSource;

Label11: TLabel;

Memo1: TMemo;

Edit8: TEdit;

Button2: TButton;

Button3: TButton;

ADOCommand1: TADOCommand;

Edit5: TEdit;

Label10: TLabel;

Button4: TButton;

Label12: TLabel;

Edit9: TEdit;

Button5: TButton;

ADOQuery1: TADOQuery;

Label13: TLabel;

Label14: TLabel;

Label15: TLabel;

Edit12: TEdit;

Button6: TButton;

ComboBox4: TComboBox;

ComboBox5: TComboBox;

StreetsDataSet: TADODataSet;

GroupDataSet: TADODataSet;

ZodiacDataSet: TADODataSet;

WorkDataSet: TADODataSet;

procedure FormCreate(Sender: TObject);

procedure Button4Click(Sender: TObject);

procedure Button1Click(Sender: TObject);

procedure Button5Click(Sender: TObject);

procedure Button6Click(Sender: TObject);

procedure TabSheet2Show(Sender: TObject);

procedure Button2Click(Sender: TObject);

procedure Button3Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

streetList: TStringList;

zodiacList: TStringList;

groupList: TStringList;

workList: TStringList;

implementation

{$R *.dfm}

procedure RefreshWork;

begin

with Form1 do

begin

WorkList.Clear;

WorkDataSet.First;

while not WorkDataSet.Eof do

begin

  WorkList.Add(WorkDataSet.Fields[0].AsString);

WorkDataSet.Next;

end;

ComboBox4.Items := WorkList;

end;

end;

procedure RefreshZodiac;

begin

with Form1 do

begin

ZodiacList.Clear;

ZodiacDataSet.First;

while not ZodiacDataSet.Eof do

begin

ZodiacList.Add(ZodiacDataSet.Fields[0].AsString);

ZodiacDataSet.Next;

end;

ComboBox5.Items := ZodiacList;

end;

end;

procedure RefreshGroups;

begin

with Form1 do

begin

groupList.Clear;

GroupDataSet.First;

while not GroupDataSet.Eof do

begin

groupList.Add(GroupDataSet.Fields[0].AsString);

GroupDataSet.Next;

end;

ComboBox2.Items := groupList;

end;

end;

procedure RefreshStreet;

begin

with Form1 do

begin

streetList.Clear;

StreetsDataSet.First;

while not StreetsDataSet.Eof do

begin

streetList.Add(StreetsDataSet.Fields[0].AsString);

StreetsDataSet.Next;

end;

ComboBox3.Items := streetList;

end;

end;

procedure TForm1.FormCreate(Sender: TObject);

const ConnStr = 'Provider=%s;Data Provider=%s;Data Source=%s';

begin

ADOConnection1.ConnectionString := Format(ConnStr,

['MSDataShape.1','Microsoft.Jet.OLEDB.4.0',

'base.mdb']);

ADODataSet1.CommandText := 'SELECT * FROM Friend';

ADODataSet1.Open;

streetList := TStringList.Create;

zodiacList := TStringList.Create;

groupList := TStringList.Create;

workList := TStringList.Create;

end;

procedure TForm1.Button4Click(Sender: TObject);

begin

ADOCommand1.CommandText := Format('INSERT INTO Streets(Street) VALUES(''%s'')',

[Edit5.Text]);

ADOCommand1.Execute;

RefreshStreet;

end;

function StrToGroup(str : string) : integer;

begin

with Form1 do

begin

ADOQuery1.SQL.Clear;

ADOQuery1.SQL.Add(Format('SELECT ID FROM Groups WHERE Name = ''%s''',[str]));

ADOQuery1.Open;

result := ADOQuery1.Fields[0].AsInteger;

end; 

end;

function StrToStreet(str : string) : integer;

begin

with Form1 do

begin

ADOQuery1.SQL.Clear;

ADOQuery1.SQL.Add(Format('SELECT ID FROM Streets WHERE Street = ''%s''',[str]));

ADOQuery1.Open;

result := ADOQuery1.Fields[0].AsInteger;

end;

end;

function StrToWork(str : string) : integer;

begin

with Form1 do

begin

result := 4;

end;

end;

function StrToZodiac(str : string) : integer;

begin

with Form1 do

begin

ADOQuery1.SQL.Clear;

ADOQuery1.SQL.Add(Format('SELECT ID FROM Zodiac WHERE Zodiac = ''%s''',[str]));

ADOQuery1.Open;

result := ADOQuery1.Fields[0].AsInteger;

end;

end;

procedure TForm1.Button5Click(Sender: TObject);

begin

ADOCommand1.CommandText := Format('INSERT INTO Groups(Name) VALUES(''%s'')',

[Edit9.Text]);

ADOCommand1.Execute;

end;

procedure TForm1.Button6Click(Sender: TObject);

begin

ADOCommand1.CommandText := Format('INSERT INTO Work(Name) VALUES(''%s'')',

[Edit12.Text]);

ADOCommand1.Execute;

end;

procedure TForm1.Button2Click(Sender: TObject);

begin

ADOCommand1.CommandText := Format('INSERT INTO Telephones([Number], [Friend]) Values(%s, %d)',

[Edit8.Text, ADODataSet1.Fields[0].AsInteger]);

ADOCommand1.Execute;

end;

procedure TForm1.Button3Click(Sender: TObject);

begin

ADOCommand1.CommandText := Format('DELETE FROM Telephones WHERE Number = %s',

[Edit8.Text]);

ADOCommand1.Execute;

end;

end.

Мы поможем в написании ваших работ!