Разработчики в FDD делятся на "хозяев классов" и "главных программистов". Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения, в ХР нет персонально ответственных за классы или методы. К работе над любым классом может привлекаться любой из участников разработки.

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

Метод разработки динамических систем (Dynamic System Development Method или DSDM).

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

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

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

DSDM неприменима если:

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

не определена группа пользователей;

проект зависит от сложных внутренних вычислений.

Основные принципы DSDM:

Активное вмешательство пользователя (в идеале, пользователи и разработчики разделяют рабочее пространство, поэтому решения могут приниматься на месте).

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

Требования заказчика - прежде всего.

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

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

Все изменения обратимы (возвращение - основная черта DSDM).

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

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

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

поддерживать полный жизненный цикл информационной системы;

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

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

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

обеспечивать минимальное время получения работоспособной системы;

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

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

Технологии характеризуются в двух измерениях: вертикальном (представляющем процессы) и горизонтальном (представляющем стадии).

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

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

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

Существуют несколько технологических подходов.

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

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

Каскадные технологические подходы.

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

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

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

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

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

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

Каркасные подходы.

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

Модель процессов Microsoft Solution Framework (MSF) представляет собой технологический подход, базирующийся на наборе моделей, правил и спецификаций, применяемых при создании и распространении программных продуктов, а также обеспечивающих более эффективное использование технологий для решений проблем бизнеса. Он позволяет количественно выражать степень завершенности работы над проектом и адаптировать методы управления им в соответствии с изменяющимися потребностями.

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

Генетические подходы.

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

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

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

Подходы на основе формальных преобразований.

Технология стерильного цеха складывается из следующих частей:

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

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

формальная верификация;

статическое тестирование.

Формальные генетические подходы

Формальное синтезирующее программирование использует математическую спецификацию - совокупность логических формул;

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

Формальное конкретизирующее программирование использует смешанные вычисления и конкретизацию по аннотациям.

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

Ранние технологические подходы быстрой разработки.

Эволюционное прототипирование - первый прототип включает создание развитого пользовательского интерфейса.

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

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

Адаптивные подходы.

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

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

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

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

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

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

Глава 4. Государственные и международные стандарты в области разработки программного обеспечения

4.1 Международный стандарт ISO/IEC 12207: 1995-08-01
Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC.

По определению, ISO 12207 - базовый стандарт процессов жизненного цикла ориентированный на различные виды ПО и типы проектов автоматизированных систем.

Целесообразность совместного использования стандартов на информационной системы и на ПО обусловливается одним из положений ISO 12207, согласно которому процессы, используемые во время жизненного цикла ПО, должны быть совместимы с процессами, используемыми во время жизненного цикла автоматизированной системы.

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

Общая структура.

В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов: приобретение, поставка, разработка и т.п.

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

Особенности стандарта ISO 12207.

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

Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация, в соответствии с конкретными проектами информационных систем. Эта адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.

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

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

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

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

Ценность стандарта ISO 12207 в том, что он содержит наборы задач, характеристик качества, критериев оценки и т.п., дающие всесторонний охват проектных ситуаций.

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

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

Общая структура.

Из всех существующих групп документов будем основываться только на группе 0 "Общие положения" и группе 6 "Создание, функционирование и развитие автоматизированной системы". Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (стадии создания автоматизированной системы), ГОСТ 34.602-89 (техническое задание на создание автоматизированной системы) и методические указания РД 50-34.698-90 (требования к содержанию документов) Стандарты предусматривают стадии и этапы выполнения работ по созданию автоматизированной системы, но не предусматривают сквозных процессов в явном виде.

Согласно ГОСТ 34, разработка автоматизированной системы разбивается на следующие этапы и стадии:

Этап формирования требований к автоматизированной системе. Состоит из следующих стадий:

обследование объекта и обоснование необходимости разработки автоматизированной системы;

формирование требований заказчика к автоматизированной системе;

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

Разработка концепции:

изучение объекта;

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

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

разработка отчета о проделанной работе.

Разработка и утверждение технического задания на разработку автоматизированной системы.

Разработка эскизного проекта автоматизированной системы:

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

разработка документации.

Разработка технического проекта:

разработка проектных решений по всей системе и по ее частям;

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

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

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

Разработка технической документации:

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

разработка и/или адаптация программного обеспечения.

Ввод разработанной системы в действие:

подготовка объекта автоматизации;

подготовка персонала;

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

монтажные работы;

пуско-наладочные работы;

предварительные испытания;

опытная эксплуатация;

приемочные испытания.

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

выполнение работ в соответствии с гарантийными обязательствами;

послегарантийное обслуживание.

В ГОСТ 34 приводится описание содержания документов, разрабатываемых на каждом из этапов.

Особенности.

Следующие основные особенности комплекса стандартов ГОСТ 34:

Основной целью разработки комплекса нормативных документов ГОСТ 34 О разрешении противоречий, возникающих при интеграции систем вследствие несогласованности нормативно-технической документации. Комплекс стандартов ГОСТ 34 более близок к схемам конкретных методик, чем к стандартам типа ISO 12207.

Степень адаптивности стандарта ГОСТ 34 определяется следующими возможностями:

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

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

возможностью вводить дополнительные документы, разделы документов и работы;

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

Стадии и этапы, выполняемые организациями - участниками работ по созданию автоматизированной системы, устанавливаются в договорах и техническом задании, что близко к подходу ISO 12207.

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

Обеспечение качества согласно ГОСТ 34 определяется в техническом заданий на автоматизированную систему и производится на любых последующих этапах и с любой степенью независимости экспертизы. В последовательности этапов разработки эти экспертизы располагаются несколько позже, чем в ISO 12207;

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

Ключевым документом взаимодействия сторон является техническое задание (ТЗ) на создание автоматизированной системы. ТЗ является основным исходным документом для создания автоматизированной системы и ее приемки, оно определяет важнейшие точки взаимодействия заказчика и разработчика.

Согласно ГОСТ 34, автоматизированная система состоит программно-технических, программно-методических комплексов и отдельных компонент организационного, технического, программного и информационного обеспечения.

4.3 Стандарты комплекса ГОСТ 19
ГОСТ 19 представляет собой всеобъемлющий комплекс, который устанавливает целевое назначение, область распространения, классификацию и правила обозначения стандартов, входящих в комплекс Единой системы программной документации (ЕСПД).

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

В стандартах ЕСПД устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ, что обеспечивает возможность:

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

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

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

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

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

В состав ЕСПД входят:

основополагающие и организационно-методические стандарты;

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

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

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

Практическая часть
Информационная система "Учебно-методический ресурс" предназначена в помощь преподавателям. С ее помощью они могут создавать работающие учебные электронные ресурсы. Эти ресурсы представляют собой web-сайты, информация которых носит учебный характер. Они содержат следующие материалы: лекции, лабораторные работы, самостоятельные работы, индивидуальные задания.

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

Информационная система "Учебно-методический ресурс" представляет собой web-сайт, поэтому в качестве языка программирования мы выбрали язык PHP. Это обусловлено несколькими причинами. Во-первых, этот язык достаточно прост в изучении, во-вторых, это многофункциональный язык, в-третьих, в него включена поддержка современных баз данных, в-четвертых, РНР поддерживается почти на всех известных платформах, почти во всех операционных системах и на самых разных серверах, в-пятых, в РНР встроены функции для работы с текстовыми данными любых форматов, включая XML, и функции для работы с файловой системой и т.д.

Для регистрации пользователей был написан файл сценария reg. php (Приложение 2). Были написаны вспомогательные функции для проверки правильности заполнения формы, проверки правильности заполнения полей, имеющих специфический характер: e-mail (имеет специальный формат), ФИО (не должны содержать цифр, знаков препинания, кроме дефиса) телефон (имеет специальный формат).

/*-------Вспомогательные функции-------*/

function Check($var, $val="") {

if (! isset($var))

return $val;

else

return $var;

}

// Функция для проверки ФИО

// function FIO_OK($str) {

// return ereg("^ [А-Яа-я\' -] {l,25}$", $str);

// }

function LOGIN_OK($str) {

$conn=mysql_connect("localhost","root"); // устанавливаем соединение

$database = "users";

$table_name = "pass";

mysql_select_db($database); // выбираем базу данных

// проверка уникальности псевдонима

$sql = "SELECT login FROM $table_name WHERE `login` = ". "'". $str. "'";

$result=mysql_query($sql);

mysql_close($conn);

return mysql_num_rows($result);

}

// Функция для проверки email

function email_OK($str) {

return preg_match("/^\w+([\. \w] +) *\w@\w((\. \w) *\w+) *\. \w{2,3}$/",$str);

}

// Функция для проверки телефона

function telefon_OK($str) {

return preg_match("/\d{3}-\d{2}-\d{2}/",$str);

}

// Функция для проверки формы

function Form_OK() {

// Массив ошибок и соответствующих сообщений

global $errors, $err_msg;

/* if(! FIO_OK($_POST ["fname"])) {

$errors ["fname"] = 1;

$_POST ["fname"] ="";

}

if(! FIO_OK($_POST ["oname"])) {

$errors ["oname"] = 1;

$_POST ["oname"] ="";

}

if(! FIO_OK($_POST ["lname"])) {

$errors ["lname"] = 1;

$_POST ["lname"] ="";

}

if(LOGIN_OK($_POST ["login"])) {

$errors ["login"] = 1;

$_POST ["login"] ="";

}

// проверка совпадения пароля и подтверждения

if(strcmp($_POST ["pass"],$_POST ["repass"]) ! =0) {

$errors ["error"] =1;

$_POST ["repass"] ="";

}

if(! $_POST ["pass"]) {

$errors ["pass"] =1;

$_POST ["repass"] ="";

}

if(! $_POST ["repass"]) $errors ["repass"] =1;

if(sizeof($errors) >0) {

// Если существуют ошибки, выводятся соответствующие сообщения, и форма отображается заново

echo "<html><body><div align='center' style='font-size: 18'><b>ОШИБКА</b></div>";

echo "<div align='center' style='font-size: 14, color: red'>Обнаружены следующие ошибки: <br>";

foreach($errors as $key=>$value) {

echo "<b>". $err_msg [$key]. "</b><br>";

}

echo "</div>";

ShowForm();

echo "</body></html>";

}

else {

// Если ошибки отсутствуют, выводится соответствующее сообщение

echo "<h2 align='center'>Уважаемый(ая)". $_POST ["lname"]. " ". $_POST ['fname']. "! </h2><br> <h3 align='center'>

Регистрация прошла успешно</h3>";

$_SESSION ['login'] =$_POST ['login'] ;

// регистрируем переменную login

// $_SESSION ['pass'] =$_POST ['pass'] ;

// регистрируем переменную pass

// теперь логин и пароль - глобальные

// переменные для этой сессии

echo "<center><a href =main_form. php>OK</a></center>";

// вносим данные в базу

$conn=mysql_connect("localhost","root"); // устанавливаем соединение

$database = "users";

$table_name = "pass";

mysql_select_db($database); // выбираем базу данных

// проверка уникальности псевдонима

$list_f = mysql_list_fields($database,$table_name); // получаем список полей в базе

$n = mysql_num_fields($list_f); // число строк в результате предыдущего запроса

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

$sql = "INSERT INTO $table_name SET "; // начинаем создавать запрос, перебираем все поля таблицы

for($i=0; $i<$n; $i++) {

$name_f = mysql_field_name ($list_f,$i); // вычисляем имя поля

$value = $_POST [$name_f] ; // вычисляем значение поля

$j = $i + 1;

$sql = $sql. $name_f. " = '$value'"; // дописываем в строку $sql пару имя=значение

if ($j <> $n) $sql = $sql. ", "; // если поле не последнее в списке, то ставим запятую

}

// перед тем как записывать что-то в базу,

// можно посмотреть, какой запрос получился

// echo $sql;

$result = mysql_query($sql,$conn); // отправляем запрос выводим сообщение успешно ли выполнен запрос

if (! $result) echo "Can't add ". $table_name;

else echo "Success! <br>";

mysql_close($conn);

}}

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

Для создания или обновления учебного курса был написан файл сценария main_form. php (Приложение 3)

Для создания части ИС "Учебно-методический ресурс", в которой осуществляется добавление новых лекций в создаваемый ресурс был написан файл сценария lections. php (Приложение 4)

Рис.5. Регистрация пользователей

В результате выполнения практической части были создан фрагмент информационной системы "Учебно-методический ресурс".

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

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

Практической частью курсовой работы была разработка фрагмента информационный системы "Учебно-методический ресурс". Такой фрагмент был создан.

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

Список используемых источников

1. Об информации, информатизации и защите информации: Федеральный закон от 20 февраля 1995 г. № 24-ФЗ // Собрание законодательства РФ. - 1995. - № 8. - Ст.609

2. Брауде, Э. Технология разработки программного обеспечения / Э. Брауде. - СПб,: Питер, 2004. - 655 с.

3. Информационные системы: учеб пособие / под ред.В.Н. Волковой, Б.И. Кузина. - 2-е изд., перераб и доп. - СПб.: Изд-во СПбГПУ, 2004. - 224 с.

4. Краткий философский словарь / под ред.А.П. Алексеева. - 2-е изд., перераб. и доп. - М.: ТК Велби, Изд-во Проспект, 2006. - 496 с.

5. Непейвода, Н.Н. Основания программирования / Н.Н. Непейвода, И.Н. Скопин. - М. - Ижевск: Ин-т компьютерных исследований, 2003. - 868 с.

6. Новый иллюстративный энциклопедический словарь / под. Ред.В.И. Бородулина, А.П. Горкина, А.А. Гусева, Н.М. Ланда и др. - М.: Большая Российская энциклопедия, 2003. - 912 с.

7. Одинцов, И.О. Профессиональное программирование. Системный подход / И.О. Одинцов. - 2-е изд., перераб. и доп. - СПб.: БХВ-Петербург, 2004. - 624 с.

8. Орлов, С.А. Технологии разработки программного обеспечения: учеб. пособие / С.А. Орлов. - 2-е изд. - СПб.: Питер, 2003. - 480 с.

9. Петров, В.Н. Информационные системы: учеб. пособие / В.Н. Петров. - СПб.: Питер, 2002. - 588 с.

10. Экономическая информатика: Введение в экономический анализ информационных систем: учебник. - М.: ИНФРА-М, 2005. - 958 с. - (Учебники экономического факультета МГУ им. М.В. Ломоносова).

11. Юдин, Э.Г. Методология науки. Системность. Деятельность / Э.Г. Юдин. - М.: Эдиториал УРСС, 1997. - 246 с.

12. Адаптивная методология ASD: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f30362e747874>

13. Адаптивные и адаптационные процессы: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f30332e747874>

14. Гибкость и монументальность методологий: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f30342e747874>

15. Единая система программной документации: [Электронный ресурс] <http://www.nist.ru/hr/doc/gost/gost19.htm>

16. Закис, А.В.ruP и другие методологии разработки ПО: [Электронный ресурс] <http://www.cmcons.com/rup-vs-competitors.htm>

17. Колодин, М.Ю.Гибкие технологии программирования (обзор и оценка применимости): [Электронный ресурс] <http://www.computer.edu.ru/myke/se/index.shtml>

18. Манифест гибкой разработки программного обеспечения: [Электронный ресурс] <http://www.agilealliance.org.ru>

19. Методологии ведения проекта: [Электронный ресурс] <http://www.digital-soft.ru/methodology.php> (11.05.2006)

20. Методологии разработки программного обеспечения: [Электронный ресурс] <http: // yura.com.ua/development/programming-methodology/index.html>

21. Понятие "Информационная система": [Электронный ресурс] <http://www.info-system.ru/is/about/is_concept_is.html>

22. Семейство методологий Crystal Алистэра Коуберна: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f3034362e747874>

23. Стандарты по информационным технологиям: [Электронный ресурс] <http://www.linux.nist.ru/hr/doc/gost/gost34.htm>

24. Сунстед, Т."Рациональное" проектирование: [Электронный ресурс] <http://www.osp.ru/cw/2001/36/017_1_print.htm>

25. Фаулер, М.Новые методологии программирования: [Электронный ресурс] <http://www.maxkir.com/sd/newmethRUS.html>

26. Хаф, Л.Методология разработки программного обеспечения: в 3-х ч.- Ч.2: Экстремальное программирование: [Электронный ресурс] <http://www.lib.csu.ru/dl/bases/prg/kompress/articles/2003_10_XP/index.htm>

27. Хаф, Л.Методология разработки программного обеспечения: в 3-х ч.- Ч.3: Rational Unified Process: [Электронный ресурс] <http://www.lib.csu.ru/dl/bases/prg/kompress/articles/2004_01_rupIntro/index.htm>

28. Экстремальное программирование и быстрая разработка: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f3034352e747874>

29. DSDM - метод разработки динамических систем: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f30372e747874>

30. Open Source как гибкая методология: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f30382e747874>

31. Rational Unified Process: [Электронный ресурс] <http://www.booktp.jino-net.ru/? action=view&article=626f6f6b2f30332f30352e747874>

Страницы: 1, 2