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

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

Рисунок
2. Каскадная модель жизненного цикла.

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

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

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

Фредерик
Брукс во втором издании своего
классического труда “Мифический
человеко-месяц” так описывает главную
беду каскадной модели [Брукс, 1995, с.245]:

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

Подборка по базе: 01.Лекция 2. Правовые и организационно — тактические основы прим, 1 глава ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ИСПОЛЬЗОВАНИЯ РЕКЛАМЫ И ПРИЕМОВ МАР, Индивидуальное практич. задание основы психотерапи.docx, Практическая 5 Основы педмастерства.doc, Метод для выполнения Конт.раб. Основы делопроизводства заочное.d, Патофизиологические основы шока.docx, РП ОГСЭ 06 Основы финансовой грамотности 10.02.05.doc, Урок 7. Контрольная работа 1 Математические основы информатики.d, Ответы — РОСДИСТАНТ — Основы архитектуры и строительных конструк, Презентация по ОБЖ _ Основы оказания первой помощи при переломах

Модели жизненного цикла
Наиболее часто говорят о следующих моделях жизненного цикла:
Каскадная (водопадная) или последовательная
Итеративная и инкрементальная – эволюционная
(гибридная, смешанная)
Спиральная (spiral) или модель Боэма
Легко обнаружить, что в разное время и в разных источниках приводится разный список моделей и их интерпретация. Например, ранее, инкрементальная модель понималась как построение системы в виде последовательности сборок (релизов), определенной в соответствии с заранее подготовленным планом и заданными (уже сформулированными) и неизменными

требованиями. Сегодня об инкрементальном подходе чаще всего говорят в контексте постепенного наращивания функциональности создаваемого продукта.
Может показаться, что индустрия пришла, наконец, к общей “правильной” модели. Однако, каскадная модель,
многократно “убитая” и теорией и практикой, продолжает встречаться в реальной жизни. Спиральная модель является ярким представителем эволюционного взгляда,
но, в то же время, представляет собой единственную модель, которая уделяет явное внимание анализу и предупреждению рисков. Поэтому, я попытался именно представленным выше образом выделить три модели –
каскадную, эволюционную и спиральную. Их мы и обсудим.
Каскадная (водопадная) модель
Данная модель предполагает строго последовательное
(во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе.
Рисунок 2. Каскадная модель жизненного цикла.

На рисунке изображены типичные фазы каскадной модели жизненного цикла и соответствующие активы проекта, являющиеся для одних фаз выходами, а для других — входами. Марри Кантор [Кантор, 2002, с.145-
146] отмечает ряд важных аспектов, характерных для водопадной модели: “Водопадная схема включает несколько важных операций, применимых ко всем проектам:
составление плана действий по разработке системы;
планирование работ, связанных с каждым действием;
применение операции отслеживания хода выполнения действий с контрольными этапами.
В связи с тем, что упомянутые задачи являются неотъемлемым элементом всех хорошо управляемых процессов, практически не существует причин,
препятствующих утверждению полнофункциональных,
классических методов руководства проектом, таких как анализ критического пути и промежуточные контрольные этапы. Я часто встречался с программными менеджерами, которые ломали себе голову над тем,
почему же столь эффективный набор методик на практике оборачивается неудачей…”
Будучи активно используема (де факто и, например, в свое время, как часть соответствующего отраслевого стандарта в США), эта модель продемонстрировала свою “проблемность” в подавляющем большинстве ИТ- проектов, за исключением, может быть, отдельных проектов обновления программных систем для критически-важных программно-аппаратных комплексов

(например, авионики или медицинского оборудования).
Практика показывает, что в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких систем (если можно говорить о “специфике” для подавляющего большинства создаваемых систем) — требования характеризуются высокой динамикой корректировки и уточнения,
невозможностью четкого и однозначного определения требований до начала работ по реализации (особенно,
для новых систем) и быстрой изменчивостью в процессе эксплуатации системы.
Фредерик Брукс во втором издании своего классического труда “Мифический человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995, с.245]:
“Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы.”
В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата
(выхода) предыдущей фазы. Однако, например,
неточность какого-либо требования или некорректная его интерпретация, в результате, приводит к тому, что приходится “откатываться” к ранней фазе проекта и требуемая переработка не просто выбивает проектную

команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался.
Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. И таких примеров проблем,
порождаемых самой природой модели, можно привести достаточно много. Достаточно для чего? Для отказа от каскадной модели жизненного цикла.
Итеративная и инкрементальная модель – эволюционный
подход
Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”,
включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации –
получение работающей версии программной системы,
включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта.
Таким образом, с завершением каждой итерации,
продукт развивается инкрементально.
С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental).
Опыт индустрии показывает, что невозможно

рассматривать каждый из этих взглядов изолировано.
Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).
Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования)
версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая”
инкрементальная модель не предполагает развертывания промежуточных сборок (релизов)
системы и все итерации проводятся по заранее определенному плану наращивания функциональности,
а пользователи (заказчик) получает только результат финальной итерации как полную версию системы. С
другой стороны, Скотт Амблер [Ambler, 2004], например,
определяет эволюционную модель как сочетание итеративного и инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47] пишет:
“Итеративную разработку называют по-разному:
инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада.” Брукс пишет
[Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:
можно очень рано начать тестирование пользователями;

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

Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.
Наиболее известным и распространенным вариантом эволюционной модели является спиральная модель,
ставшая уже по сути самостоятельной моделью,
имеющей различные сценарии развития и детализации.
Спиральная модель
Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри Боэмом (Barry Boehm)
в 1988 году [Boehm, 1988]. Отличительной особенностью этой модели является специальное внимание рискам,
влияющим на организацию жизненного цикла.

Боэм формулирует “top-10” наиболее распространенных
(по приоритетам) рисков (используется с разрешения автора):
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах,
определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. “Разрыв” в квалификации специалистов разных областей знаний.
11. Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.

Рисунок 4. Оригинальная спиральная модель жизненного цикла разработки по Боэму
(используется с разрешения автора) [Boehm,
1988]
Сам Барри Боэм так характеризует спиральную модель разработки (используется с разрешения автора):
“Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время, ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях

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

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

возникающих в результате одинакового уделения внимания как обычному сопровождению, так и критичным вопросам, связанным с расширением функциональности продукта, всегда ассоциированным с повышенными рисками.
Модель позволяет решать интегрированный задачи системной разработки, охватывающей и программную и аппаратную составляющие создаваемого продукта. Подход, основанный на управлении рисками и возможности своевременного отбрасывания непривлекательных альтернатив (на ранних стадиях проекта) сокращает расходы и одинаково применим и к аппаратной части, и к программному обеспечению.”
Описывая созданную спиральную модель, Боэм обращает внимание на то, что обладая явными преимуществами по сравнению с другими взглядами на жизненный цикл, необходимо уточнить, детализировать шаги, т.е. циклы спиральной модели для обеспечения целостного контекста для всех лиц, вовлеченных в проект (Боэм это формулирует так: “Need for further elaboration of spiral model steps. In general, the spiral model process steps need further elaboration to ensure that all software development participants are operating in a consistent context.”). Организация ролей
(ответственности членов проектной команды),
детализация этапов жизненного цикла и процессов,
определение активов (артефактов), значимых на разных этапах проекта, практики анализа и предупреждения рисков – все это вопросы уже конкретного процессного

фреймворка или, как принято говорить, методологии
разработки.
Действительно, детализация процессов, ролей и активов
– вопрос методологии. Однако, рассматривая
(спиральная) модель разработки, являясь концептуальным взглядом на создание продукта,
требует, как и в любом проекте, определения ключевых
контрольных точек проекта — milestones. Это, в большой степени, связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный для менеджеров и лидеров проектов, отслеживающих ход их выполнения и планирующих дальнейшие работы. В 2000
году [Boehm, 2000], представляя анализ использования спиральной модели и, в частности, построенного на его основе подхода MBASE — Model-Based (System)
Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых характеристик или практик,
обеспечивающих успешное применение спиральной модели:
1. Параллельное, а не последовательное определение артефактов (активов) проекта
2. Согласие в том, что на каждом цикле уделяется внимание:
целям и ограничениям, важным для заказчика альтернативам организации процесса и технологических решений, закладываемых в продукт идентификации и разрешению рисков оценки со стороны заинтересованных лиц (в первую очередь заказчика)
достижению согласия в том, что можно и необходимо двигаться дальше

1. Использование соображений, связанных с рисками,
для определения уровня усилий, необходимого для каждой работы на всех циклах спирали.
2. Использование соображений, связанных с рисками,
для определения уровня детализации каждого артефакта, создаваемого на всех циклах спирали.
3. Управление жизненным циклом в контексте обязательств всех заинтересованных лиц на основе трех контрольных точек:
Life Cycle Objectives (LCO)
Life Cycle Architecture (LCA)
Initial Operational Capability (IOC)
1. Уделение специального внимания проектным работам и артефактам создаваемой системы
(включая непосредственно разрабатываемое программное обеспечение, ее окружение, а также эксплуатационные характеристики) и жизненного цикла (разработки и использования).
Эволюционирование спиральной модели, таким образом, связано с вопросами детализации работ.
Особенно стоит выделить акцент на большем внимании вопросам уточнения – требований, дизайна и кода, т.е.
придание большей важности вопросам итеративности, в том числе, увеличения их количества при сокращении длительности каждой итерации.
В результате, можно определить общий набор контрольных точек в сегодняшней спиральной модели:
Concept of Operations (COO) – концепция
<использования> системы;

Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
Initial Operational Capability (IOC) – первая версия создаваемого продукта, пригодная для опытной эксплуатации;
FinalOperationalCapability (FOC) – готовый продукт,
развернутый (установленный и настроенный) для реальной эксплуатации. Таким образом, мы приходим к возможному современному взгляду (см.,
например, представление спиральной модели в
[Фатрелл, Шафер и Шафер, 2003, с.159]) на итеративный и инкрементальный – эволюционный жизненный цикл в форме спиральной модели,
изображенной на рисунке 5.

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

конкретными участниками проектных команд. В
совокупности с процессами и активами (артефактами)
они позволяют нам создать целостную и подробную картину жизненного цикла.
Так как взглядов на детализацию описания жизненного цикла может быть много – безусловно, существуют различные методологии, среди которых наибольшее распространение получили:
Rational Unified Process (RUP)
Enterprise Unified Process (EUP)
Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и MSF for CMMI
(анонсированная изначально как “MSF Formal”)
Agile-практики (eXtreme Programming (XP), Feature
Driven Development (FDD), Dynamic Systems
Development Method (DSDM), SCRUM,…).

Источник

Модели жизненного цикла программного обеспечения

Одним из ключевых понятий управления проектами, в том числе в приложении к
индустрии программного обеспечения, является жизненный цикл проекта (Project
Lifecycle Management — PLM).

Известный эксперт по управлению высокотехнологичными проетами Арчибальд так
определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р.,
2005]:

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

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

Существует общее соглашение о выделении четырех обобщенных фаз жизненного
цикла (в скобках приведены используемые в различных источниках альтернативные
термины):

концепция (инициация, идентификация, отбор)
определение (анализ)
выполнение (практическая реализация или внедрение, производство и
развертывание, проектирование или конструирование, сдача в эксплуатацию,
инсталляция, тестирование и т.п.)
закрытие (завершение, включая оценивание после завершения)

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

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

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

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

Ниже приведены определения <модели> жизненного цикла программной системы,
даваемые, например, в различных вариантах стандартов ГОСТ:

Модель жизненного цикла — структура, состоящая из процессов, работ и задач,
включающих в себя разработку, эксплуатацию и сопровождение программного
продукта, охватывающая жизнь системы от установления требований к ней до
прекращения ее использования [ГОСТ 12207, 1999].
Жизненный цикл автоматизированной системы (АС) — совокупность взаимосвязанных
процессов создания и последовательного изменения состояния АС, от формирования
исходных требований к ней до окончания эксплуатации и утилизации комплекса
средств автоматизации АС [ГОСТ 34, 1990].

Один из них — ГОСТ Р ИСО/МЭК 12207 является переводом международного стандарта
ISO/IEC 12207, на основе которого, в свою очередь, создан соответствующий
стандарт IEEE 12207. Второй – в рамках семейства ГОСТ 34 – разрабатывался в
СССР самостоятельно, как стандарт на содержание и оформление документов на
программные системы в рамках Единой системы программной документации (ЕСПД) и
Единой системы конструкторской документации (ЕСКД). В последние годы, акцент
делается на стандарты ГОСТ, соответствующие международным стандартам. В то же
время, 34-я серия является важным дополнительным источником информации для
разработки и стандартизации внутрикорпоративных документов и формирования
целостного понимания и видения концепций жизненного цикла в области
программного обеспечения.

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

Скотт Амблер (Scott W. Ambler) [Ambler, 2005], автор концепций и практик
гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение
Rational Unified Process), предлагает следующие уровни жизненного цикла,
определяемые соответствующим содержанием работ (см. рис.1):

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

В данном контексте, SWEBOK описывает области знаний жизненного цикла системы
и жизненного цикла разработки программного обеспечения. В свою очередь, как
упоминается в SWEBOK, одним из фундаментальных взглядов на жизненный цикл
является стандарт процессов жизненного цикла ISO/IEC, IEEE, ГОСТ Р ИСО/МЭК
12207.

Стандарт 12207: Процессы жизненного цикла программного обеспечения

В 1997 году Международная Организация по Стандартизации — ИСО (International
Organization for Standardization — ISO) и Международная Электротехническая
Комиссия — МЭК (International Electrotechnical Commission — IEC) создали
Совместный Технический Комитет по Информационным Технологиям — Joint Technical
Committee (JTC1) on Information Technology. Содержание работ JTC1 определено
как “стандартизация в области систем и оборудования информационных технологий
(включая микропроцессорные системы)”. В 1989 году этот комитет инициировал
разработку стандарта ISO/IEC 12207, создав для этого подкомитет SC7
(SuСommittee 7) по программной инженерии. Соответствующий стандарт впервые был
опубликован 1-го августа 1995 года под заголовком “Software Life Cycle
Processes” – “Процессы жизненного цикла программного обеспечения”. Национальный
стандарт [ГОСТ 12207, 1999] получил название “Процессы жизненного цикла
программных средств”.

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

Данный стандарт определяет жизненный цикл как структуру декомпозиции работ.
Детализация, техники и метрики проведения работ – вопрос программной инженерии.
Организация последовательности работ – модель жизненного цикла. Совокупность
моделей, процессов, техник и организации проектной группы задаются
методологией. В частности, выбор и применение метрик оценки качества
программной системы и процессов находятся за рамками стандарта 12207, а
концепция совершенствования процессов рассматривается в стандарте ISO/IEC 15504
“Information Technology — Software Process Assessment” (“Оценка процессов <в
области> программного обеспечения”).

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

Организация стандарта и архитектура жизненного цикла

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

Стандарт описывает 17 процессов жизненного цикла, распределенных по трем
категориям – группам процессов (названия представлены с указанием номеров
разделов стандарта, следуя определениям на русском и английском языке,
определяемыми [ГОСТ 12207, 1999] и оригинальной версией ISO/IEC 12207,
соответственно):

Основные процессы жизненного цикла — Primary Processes

5.1 Заказ — Acqusition
5.2 Поставка — Supply
5.3 Разработка — Development
5.4 Эксплуатация — Operation
5.5 Сопровождение — Maintenance

Вспомогательные процессы жизненного цикла – Supporting Processes

6.1 Документирование — Documentation
6.2 Управление конфигурацией – Configuration Management
6.3 Обеспечение качества – Quality Assurance
6.4 Верификация — Verification
6.5 Аттестация — Validation
6.6 Совместный анализ – Joint Review
6.7 Аудит — Audit
6.8 Решение проблем – Problem Resolution

Организационные процессы жизненного цикла – Organizational Processes

7.1 Управление — Management
7.2 Создание инфраструктуры — Infrastructure
7.3 Усовершенствование — Improvement
7.4 Обучение — Training

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

Дерево процессов жизненного цикла представляет собой структуру декомпозиции
жизненного цикла на соответствующие процессы (группы процессов). Декомпозиция
процессов строится на основе двух важнейших принципов , определяющих правила
разбиения (partitioning) жизненного цикла на составляющие процессы. Эти
принципы:

Модульность

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

Ответственность

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

Общая иерархия (декомпозиция) составных элементов жизненного цикла выглядит
следующим образом:

группа процессов
** процессы
*** работы
**** задачи

В общем случае, разбиение процесса базируется на широко распространенном PDCA-цикле:

“P” – Plan – Планирование
“D” – Do – Выполнение
“C” – Check – Проверка
“A” – Act – Реакция (действие)

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

Основные процессы жизненного цикла

Приобретение (5.1)

Процесс приобретения (как его называют в ГОСТ – “заказа”) определяет работы и
задачи заказчика, приобретающего программное обеспечение или услуги, связанные
с ПО, на основе контрактных отношений. Процесс приобретения состоит из
следующих работ (названия ГОСТ 12207 даны в скобках, если предлагают другой
перевод названий работ оригинального стандарта):

Inititation – инициирование (подготовка)
Request-for-proposal preparation – подготовка запроса на предложение
(подготовка заявки на подряд)
Contract preparation and update –подготовка и корректировка договора
Supplier monitoring – мониторинг поставщика (надзор за поставщиком)
Acceptance and completion – приемка и завершение (приемка и закрытие договора)

Все работы проводятся в рамках проектного подхода.

Поставка (5.2)

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

Inititation – инициирование (подготовка)
Preparation of response – подготовка предложения (подготовка ответа)
Contract – разработка контракта (подготовка договора)
Planning — планирование
Execution and control – выполнение и контроль
Review and evaluation –проверка и оценка
Delivery and completion – поставка и завершение (поставка и закрытие
договора)

Разработка (5.3)

Процесс разработки определяет работы и задачи разработчика. Процесс состоит из
следующих работ:

Process implementation – определение процесса (подготовка процесса)
System requirements analysis – анализ системных требований (анализ требований
к системе)
System design – проектирование системы (проектирование системной архитектуры)
Software requirements analysis – анализ программных требований (анализ
требований к программным средствам)
Software architectural design – проектирование программной архитектуры
Software detailed design – детальное проектирование программной системы
(техническое проектирование программных средств)
Software coding and testing – кодирование и тестирование (программирование и
тестирование программных средств)
Software integration – интеграция программной системы (сборка программных
средств)
Software qualification testing – квалификационные испытания программных
средств
System integration – интеграция системы в целом (сборка системы)
System qualification testing – квалификационные испытания системы
Software installation – установка (ввод в действие)
Software acceptance support – обеспечение приемки программных средств

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

Эксплуатация (5.4)

Процесс разработки определяет работы и задачи оператора службы поддержки.
Процесс включает следующие работы:

Process implementation – определение процесса (подготовка процесса)
Operational testing – операционное тестирование (эксплуатационные испытания)
System operation – эксплуатация системы
User support – поддержка пользователя

Сопровождение (5.5)

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

Process implementation – определение процесса (подготовка процесса)
Problem and modification analysis – анализ проблем и изменений
Modification implementation – внесение изменений
Maintenance review/acceptance – проверка и приемка при сопровождении
Migration – миграция (перенос)
Software retirement – вывод программной системы из эксплуатации (снятие с
эксплуатации)

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

Адаптация стандарта

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

Адаптация включает следующие виды работ:

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

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

Необходимо отметить, что существует еще один стандарт жизненного цикла —
ISO/IEC 15288 (выпущен в 2002 году), фокусирующийся на вопросах организации
процессов жизненного цикла системного уровня (Life Cycle Processes – System) и
включающий специальный процесс — “Tailoring”, т.е. настройку, адаптацию
жизненного цикла к конкретным требованиям и ограничениям, существующим или
принятым в конкретной организации/подразделении или для заданного проекта.

Модели жизненного цикла

Наиболее часто говорят о следующих моделях жизненного цикла:

Каскадная (водопадная) или последовательная
Итеративная и инкрементальная – эволюционная (гибридная, смешанная)
Спиральная (spiral) или модель Боэма

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

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

Каскадная (водопадная) модель

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

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

входами. Марри Кантор [Кантор, 2002, с.145-146] отмечает ряд важных аспектов,
характерных для водопадной модели: “Водопадная схема включает несколько важных
операций, применимых ко всем проектам:
составление плана действий по разработке системы;
планирование работ, связанных с каждым действием;
применение операции отслеживания хода выполнения действий с контрольными
этапами.

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

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

Фредерик Брукс во втором издании своего классического труда “Мифический
человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995,
с.245]:

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

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

Итеративная и инкрементальная модель – эволюционный подход

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

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

Эволюционная модель подразумевает не только сборку работающей (с точки зрения
результатов тестирования) версии системы, но и её развертывание в реальных
операционных условиях с анализом откликов пользователей для определения
содержания и планирования следующей итерации. “Чистая” инкрементальная модель
не предполагает развертывания промежуточных сборок (релизов) системы и все
итерации проводятся по заранее определенному плану наращивания
функциональности, а пользователи (заказчик) получает только результат финальной
итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler,
2004], например, определяет эволюционную модель как сочетание итеративного и
инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47]
пишет: “Итеративную разработку называют по-разному: инкрементальной,
спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины
разный смысл, но эти различия не имеют широкого признания и не так важны, как
противостояние итеративного метода и метода водопада.”
Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:

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

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

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

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

Спиральная модель (представлена на рисунке 4) была впервые сформулирована Барри
Боэмом (Barry Boehm) в 1988 году [Boehm, 1988]. Отличительной особенностью этой
модели является специальное внимание рискам, влияющим на организацию жизненного
цикла.

Боэм формулирует “top-10” наиболее распространенных (по приоритетам) рисков
(используется с разрешения автора):

Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
“Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание
деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы
или вовлеченных в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
“Разрыв” в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами
взаимодействия специалистов в проектной команде.

Сам Барри Боэм так характеризует спиральную модель разработки (используется с
разрешения автора):

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

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

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

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

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

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

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

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

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

Описывая созданную спиральную модель, Боэм обращает внимание на то, что обладая
явными преимуществами по сравнению с другими взглядами на жизненный цикл,
необходимо уточнить, детализировать шаги, т.е. циклы спиральной модели для
обеспечения целостного контекста для всех лиц, вовлеченных в проект (Боэм это
формулирует так: “Need for further elaboration of spiral model steps. In
general, the spiral model process steps need further elaboration to ensure that
all software development participants are operating in a consistent context.”).
Организация ролей (ответственности членов проектной команды), детализация
этапов жизненного цикла и процессов, определение активов (артефактов), значимых
на разных этапах проекта, практики анализа и предупреждения рисков – все это
вопросы уже конкретного процессного фреймворка или, как принято говорить,
методологии разработки.

Действительно, детализация процессов, ролей и активов – вопрос методологии.
Однако, рассматривая (спиральная) модель разработки, являясь концептуальным
взглядом на создание продукта, требует, как и в любом проекте, определения
ключевых контрольных точек проекта — milestones. Это, в большой степени,
связано с попыткой ответить на вопрос “где мы?”. Вопрос, особенно актуальный
для менеджеров и лидеров проектов, отслеживающих ход их выполнения и
планирующих дальнейшие работы.
В 2000 году [Boehm, 2000], представляя анализ использования спиральной модели
и, в частности, построенного на его основе подхода MBASE — Model-Based (System)
Architecting and Software Engineering (MBASE), Боэм формулирует 6 ключевых
характеристик или практик, обеспечивающих успешное применение спиральной
модели:

Параллельное, а не последовательное определение артефактов (активов) проекта
Согласие в том, что на каждом цикле уделяется внимание:

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

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

Life Cycle Objectives (LCO)
Life Cycle Architecture (LCA)
Initial Operational Capability (IOC)

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

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

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

Concept of Operations (COO) – концепция <использования> системы;
Life Cycle Objectives (LCO) – цели и содержание жизненного цикла;
Life Cycle Architecture (LCA) – архитектура жизненного цикла; здесь же
возможно говорить о готовности концептуальной архитектуры целевой программной
системы;
Initial Operational Capability (IOC) – первая версия создаваемого продукта,
пригодная для опытной эксплуатации;
FinalOperationalCapability (FOC) – готовый продукт, развернутый
(установленный и настроенный) для реальной эксплуатации.
Таким образом, мы приходим к возможному современному взгляду (см., например,
представление спиральной модели в [Фатрелл, Шафер и Шафер, 2003, с.159]) на
итеративный и инкрементальный – эволюционный жизненный цикл в форме спиральной
модели, изображенной на рисунке 5.

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

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

Rational Unified Process (RUP)
Enterprise Unified Process (EUP)
Microsoft Solutions Framework (MSF) в обоих представлениях: MSF for Agile и
MSF for CMMI (анонсированная изначально как “MSF Formal”)
Agile-практики (eXtreme Programming (XP), Feature Driven Development (FDD),
Dynamic Systems Development Method (DSDM), SCRUM,…).

Источник

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

Введение

программный
редактирование методология диаграмма

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

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

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

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

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

Методология RAD неприменима для построения сложных расчетных программ,
операционных систем или программ управления космическими кораблями, т.е.
программ, требующих написания большого объема (сотни тысяч строк) уникального
кода.

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

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

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

. Достаточная информация обо всех объектах.

. Многофункциональность.

Рекомендуемые аппаратные требования:

· процессор Intel Pentium IV 1.7 ГГц;

· 512MB
оперативной памяти;

· 16MB видеопамяти;

· Свободное местно на жестком диске, равный 25Мб.

Требования к программному обеспечению: ОС MS Windows XP или выше, набор драйверов.

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

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

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

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

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

В приложение 1 приведён полный состав сопутствующей проекту документации,
с оглавлением состава и с краткими выдержками их содержимого.

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

Цели и задачи работы

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

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

Задачи работы:

1. Разработать программу, в которой будет возможность составление тестов
и сохранение их в формате tes.
Развёрнутое функциональное наименование проекта: «Система тестирования знаний».

2. Реализация всевозможных функций.

3. Более детальна настройка аудио треков.

Новизна работы

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

Практическая значимость

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

Структура и объем работы

Пояснительная записка к курсовой работе состоит из введения, трех
разделов и заключения, содержит 18 рисунков и 3 таблицы. Список использованной
литературы содержит 21 наименований. Общий объём пояснительной записки — 55
страниц машинописного текста, введение — 5 страницы, основная часть — 31
страницы, заключение — 1, приложения — 21 страниц.

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

В первом разделе представлено описание предметной области.

Во втором разделе описано проектирование программного продукта.

В третьем разделе описана программная реализация.

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

В приложение 1 описание техническое задание.

В приложение 2 описание руководство пользователя.

В приложение 3 представлен листинг программы

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

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

Для достижения поставленной цели должно быть реализовано:

·
изучение
структуры создания и редактирования тестов;

·
изучение основной
документации, необходимой для создания и редактирования тестов;

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

·
ознакомление со
структурой организации создания и редактирования тестов;

·
формирование
пакета документации;

·
проведение тестирования
и отладка проекта;

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

·
простота в
использовании и обучении пользования программой.

Задачи программного продукта:

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

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

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

Входные данные: учебный материал.

Выходные данные: тесты для прохождения тестирования.

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

Работа с программой проходит в одном режиме — режиме пользователя. В нем
выполняются все действия по работе с программой.

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

1. Требования бизнеса:

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

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

2. Требования пользователя:

· устойчиво работать в течение длительного времени;

· работать под операционной системой семейства Windows;

· выдавать в сообщениях понятную информацию;

· иметь надписи на кнопках понятные для пользователя;

· иметь эргономичное цветовое оформление;

· иметь надписи, свободно читаемые (кегль шрифта 10-14 пт.);

· быть способной параллельно работать с другими приложениями.

3. Функциональные требования:

· Должна быть обеспечена возможность ввода, изменения данных и
их удаления;

· в программе должен быть удобный понятный и интерфейс;

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

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

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

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

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

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

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

2. Проектирование программного обеспечения

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

У каждого программного продукта существует свой жизненный цикл (ЖЦ). ЖЦ —
это непрерывный процесс, который начинается с момента принятия решения о
необходимости создания ПП и заканчивается моментом полного изъятия ПП из
эксплуатации. Современный рынок программного обеспечения требует, чтобы выпуск
программ был быстрым, а его дальнейшая эксплуатация — долговременной и
надежной. Для достижения этого необходима хорошая организация и тщательное
планирование всего жизненного цикла программного продукта. Жизненный цикл
программ состоит из нескольких этапов: Анализ предметной области,
проектирование, реализация, анализ и тестирование, эксплуатация.

В настоящее время широкое распространены 2 модели жизненного цикла:

. Каскадная

. Спиральная

Каскадная

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

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

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

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

Преимуществами каскадной модели являются:

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

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

· Удобна для ПП, где уже в начале достаточно полно сформулированы
все требования.

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

Спиральная

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

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

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

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

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

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

Преимущества:

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

От этапа к этапу можно переходить до завершения работ на предыдущем
этапе.

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

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

2.2 Фаза проектирования

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

На фазе проектирования происходит:

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

Внешние спецификации включают в себя:

внешние интерфейсы;

функциональное наполнение, видимое пользователю;

взаимодействие между процессами;

форматы файлов;

Внутренние спецификации включают в себя:

реализация интерфейсов;

реализация функционального наполнения;

внутренние структуры данных;

описание алгоритмов;

внутренняя обработка ошибок.

. План тестирования. Данный план работает по следующим пунктам:

структура и среда тестовой системы;

методология тестирования;

— периодичность
тестирования.

. План информационной разработки.

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

· SADT (Structured Analysis and Design Technique) модели и соответствующие
функциональные диаграммы;

· DFD (Data Flow Diagrams) диаграммы потоков данных;

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

SADT-диаграмма

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

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

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

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

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

Рис.2.2.1. SADT-диаграмма

Рис.2.2.2. Декомпозиция SADT-диаграммы

DFD-диаграмма

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

Рис.
2.2.3. DFD — диаграмма

1.
На этапе проектирования проведен структурный анализ программного продукта,
рассмотрены основные модели жизненного цикла программного продукта, и построены
соответствующие диаграммы: SADT-диаграмма и DFD-диаграмма.

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

3.Программная реализация

.1 Выбор средства для разработки

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

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

C++ Builder позволяет решать следующий круг
задач:

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

· Создавать приложения любой сложности и любого назначения:
офисные, бухгалтерские, инженерные, информационно-поисковые — никаких преград
перед C++ Builder и лежащим в его основе языком C++ нет.

· Создавать современный пользовательский интерфейс для любых
ранее разработанных программ DOS и Windows. Нередко в учреждении или фирме существуют
и успешно эксплуатируются прикладные программы, разработанные в разное время,
разными коллективами, для разных операционных систем. С помощью C++ Builder эти приложения можно снабдить современным удобным
оконным интерфейсом, объединить разрозненные приложения в единую систему,
обеспечить их стилистическое единство, наладить обмен информации между
приложениями.

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

· Создавать мощные системы работы с локальными и удаленными
базами данных любых типов. Подход, используемый в C++ Builder,
позволяет получить доступ к базам, созданным на любой платформе: InterBase, Microsoft Access, FoxPro,
Paradox, dBase, Sybase,
Microsoft SQL, Oracle
и др.

· Создавать базы данных многих типов с помощью инструментария C++ Builder.

· Автономно отлаживать приложения работы с базами данных на
локальном сервере InterBase,
поставляемом вместе с C++ Builder, с последующим выходом в сеть.

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

· Связываться из своего приложения с такими продуктами Microsoft, как Word, Excel
и другие, используя все их богатейшие возможности.

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

· Создавать профессиональные программы установки приложений Windows, учитывающие всю специфику и все
требования Windows. В частности, для этого можно
использовать поставляемую вместе с C++ Builder программу InstallShield Express.

· и много другое.

Достоинства и недостатки C++ Builder

Достоинства

. Все преимущества C, хотя более медлителен.

. Классы и объекты делают программы более масштабируемыми.

. Строгая типизированность — защищает от ошибок.

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

Недостатки

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

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

. Строгая типизированность тормозит разработку.Access

База данных в MS Access представляет собой совокупность
инструментов для ввода, хранения, просмотра, выборки и управления информацией.
К этим средствам относятся таблицы, формы, отчеты, запросы.

Программный продукт MS Access представляет собой настольную систему
управления базами данных (СУБД). Понятие «настольная» СУБД указывает
на то, что все операции с базой данных осуществляются на локальном компьютере
пользователя. То есть база данных в MS Access —
совокупность инструментов для ввода, хранения, просмотра, выборки и управления
информацией. К этим средствам относятся таблицы, формы, отчеты, запросы.
Противоположностью настольной системе является распределенная база данных, т.
е. такая архитектура, при которой ядро БД работает на выделенном сервере; там
же обычно хранятся и данные. Через локальную или глобальную сеть пользователь
посредством установленного на своем компьютере программного обеспечения
посылает запросы и получает ответы. Такие системы предназначены для работы с
большим количеством клиентов, и зачастую в качестве серверов в них функционируют
компьютеры более сложные и мощные. Так же программа успешно работает и в сетях,
правда, с ограниченным числом клиентов.

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

Преимуществами перед другими средами разработки могут служить следующие
критерии:

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

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

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

Язык запросов SQL

Delphi-
язык и среда программирования, относящаяся к классу RAD- (Rapid Application
Development — «Средство быстрой разработки приложений») средств CASE —
технологии. Delphi сделала разработку мощных приложений Windows быстрым
процессом, доставляющим вам удовольствие. Приложения Windows, для создания
которых требовалось большое количество человеческих усилий, например в C++, могут быть легко написаны одним
человеком, использующим Delphi.обладает широким набором возможностей, начиная
от проектировщика форм и кончая поддержкой всех форматов популярных баз данных.
Также здесь имеются предварительно определенные визуальные и невизуальные
объекты, включая кнопки, объекты с данными, меню и уже построенные диалоговые
панели. С помощью этих объектов можно, например, обеспечить ввод данных просто
несколькими нажатиями кнопок мыши, не прибегая к программированию. Это
наглядная реализация применений CASE-технологий в современном программировании
приложений. Та часть, которая непосредственно связана с программированием
интерфейса пользователя, системой получила название визуальное
программирование.

Любой из данных языков программирования подходит под описания RAD.

— необязательность полного завершения работ на каждом из этапов
жизненного цикла (спиральная модель);

обязательное вовлечение пользователей в процесс разработки проекта;

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

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

Для проекта «Система тестирования знаний» был выбран язык
программирования Delphi. На нем в наше время реализуются как простые, домашние
программы, так и сложнейшие проекты для самых ведущих корпораций мира.

.2 Реализация программного продукта

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

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

· определяется необходимость распределения данных;

· производится анализ использования данных;

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

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем
согласованным требованиям.

Таким образом, на фазе реализации происходит:

1. Разработка программного обеспечения:

2. Подготовка к внедрению.

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

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

Рис.3.2.1 Главное окно «Система тестирования знаний».

Здесь показано, что можно выбрать готовый проект и создать новый.

Рис.3.2.2 Окно создания нового проекта

Project Title — Это
название справки

Остальные пункты не нужны.

Рис.3.2.3 Окно ввода данных для каждой блок-схемы.

Topics
— это странички справки.

В эти странички пишем необходимые нам данные.

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

Рис.3.2.4 Окно «Проектировщика расположения» в будущей справке.

Здесь в первую очередь нажимаем на кнопку Book, затем вставляем нужные нам странички (Topics) с нужным нам пояснением. Далее
вставляем готовые странички с помощью кнопки Topics.

Потом двойным щелчком на значок Book в окне — переименовываем название Система тестирования знаний.

Кнопка Remove — отвечает за удаление ненужных
страничек.

Рис.3.2.5. Окно «Проектировщика расположения» в будущей справке.

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

3.3 Работа справки в программе «Система тестирования знаний»

void
__fastcall TForm3::Button3Click(TObject *Sender)
— описана функция нажатия кнопки, т.е. при нажатие кнопки выполняется:

{

Application->HelpCommand(HELP_CONTEXT,3);
— открывается 3 страница справки (вычисление).

}

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

Фаза внедрения состоит из этапов:

1. комплексные испытания;

2. подготовка кадров для эксплуатации;

. подготовка документации;

. сдача заказчику;

. ввод в эксплуатацию;

. сопровождение системы;

. поддержка;

. сервисное обслуживание.

В ходе программной реализации была проделана следующая работа:

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

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

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

. Создана справки с помощью программы «Система тестирования знаний».
Реализован программный код.

Заключение

1. В процессе данной работы были достигнуты заданные цели и выполнены
все задачи, поставленные перед автором.

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

. На этапе проектирования проведен структурный анализ программного
продукта, рассмотрены основные модели жизненного цикла программного продукта, и
построены соответствующие диаграммы: SADT-диаграмма и DFD-диаграмма.

. Выбраны технологии реализации программной системы: выбрана среда
разработки Delphi для реализации ПП и приведены
обоснования для этого выбора.

. Реализованы основные алгоритмы и модули программной системы, в
результате чего получили готовый ПП.

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

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

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

.Дж. Банкел,
Фундаментальные алгоритмы и структура данных в Delphi изд. Москва Dia Soft
2003г.Дж. Банкел, Фундаментальные алгоритмы и структура данных в Delphi изд.
Москва Dia Soft 2003г.

.Брябрин В.М.
Программное обеспечение персональных ЭВМ. Изд. 2-е, стер. — М.: Наука, 1989г.

.Архангельский
А.Я., Программирование в Delphi 7. — М.: Бином, 2005. -1152 с.

.Марка Д.А.,
МакГоуэн К. Методология структурного анализа и проектирования. М.,
«МетаТехнология», 1993.

.Рассел
Арчибальд. Модели жизненного цикла высокотехнологичных проектов.
#»562442.files/image009.gif»>

Рис.5.1 Главное окно программы для тестирования.

Рис.5.2 Главное окно программы для редактирования тестов

Описание основных элементов интерфейса

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

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

Рис.5.3 Файл.

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

Рис.5.4 Файл.

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

Рис.5.5 Тест.

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

Рис.5.6 Настройки.

Основные принципы и порядок работы

Работа с программой начинается с создание теста в редакторе тестов
программы «Test v.1.0».

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

Извлечение данных возможно из тестовых файлов следующих формата: TES (*.tes).

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

Рис. 5.7 Новый тест.

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

При создании теста нужно вводить данные по вопросу, варианты ответов и
правильный вариант ответа.

Рис. 5.8 Первый вопрос теста.

После завершения редактирования теста производится его сохранение.

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

Далее после сохранения теста, открываем его с помощью программы для тестирования
знаний «Test v.1.0» и нажимаем во вкладке Тест, на кнопку начать
тестирование. Вводим пароль, если изначально создали тест с паролем.

Рис. 5.9 Пароль.

Рис. 5.10 Открытый тест.

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

Рис. 5.11 Результаты тестирования.

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

Некоторые моменты, которые следует учитывать, при работе

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

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

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

Условия распространения

Созданная программа будет распространяться платно.

Информация о разработчиках

Данный программный продукт разработан студентом 3 курса Института
информатики и телематики, группа 38: Хаитов И. Д.

Установка программного продукта

Программу «Система тестирования знаний» не нужно устанавливать.
Достаточно запустить двойным щелчком мыши и программа работает.

Удаление программного продукта

Удаления программы происходит простым помещением ее в корзину.

П.3. ПРОГРАММНЫЙ КОД

unit Unit1;

interface, Messages, SysUtils, Classes, Graphics, Controls,
Forms, Dialogs, StdCtrls, Menus, ExtCtrls, uEncrypt;

// Временной тип= Record: Byte;: Byte;;= class(TForm):
TMainMenu;: TMenuItem;: TPanel;_Last: TLabel;_FQuestion: TLabel;: TButton;:
TButton;: TButton;: TButton;: TMemo;: TMenuItem;: TTimer;: TMenuItem;:
TMenuItem;: TMenuItem;_Temp: TMemo;: TMemo;: TMemo;: TMemo;: TMemo;:
TOpenDialog;: TGroupBox;: TMenuItem;: TMenuItem;: TLabel;: TLabel;: TLabel;:
TPanel;: TLabel;_NomQuestion: TLabel;: TMenuItem;_OptionInfoAnsver: TMenuItem;:
TLabel;: TLabel;: TEdit;: TEdit;: TLabel;: TEdit;FormCreate(Sender:
TObject);DecTime(Var aa:TPrTime; Sender: TObject): string;PrTimeOut(Sender:
TObject);Timer1Timer(Sender: TObject);MIOpenFileClick(Sender:
TObject);MIAboutClick(Sender: TObject);PrFillFileds(Sender:
TObject);MITBeginClick(Sender: TObject);PrClickButton(Sender:
TObject);MIExitClick(Sender: TObject);MI_OptionInfoAnsverClick(Sender:
TObject);PrGetDataTest(Sender: TObject);FormClose(Sender: TObject; var Action:
TCloseAction);MITEndClick(Sender: TObject);

{ Private declarations }

{ Public declarations }

// Изменено: string;: TPrTime;: byte;

// — Суммарное количество вопросов теста: byte;;: TForm1;:
TPrTime;: TPrTime;

// поряд. номер вопроса: Byte;

// кол-во прав. ответов

PrVAnsverOK: Byte;

PriznakExit:boolean;

// — Массив храняший номера вопросов —

PrOrderQuestion: array [1..255] of byte;Unit3;

{$R *.DFM}TForm1.FormCreate(Sender:
TObject);.Visible:=False;.Enabled:=False;.Min:=0;.Sec:=0;.Enabled:=True;.Enabled:=False;:=1;_Temp.Lines.Clear;:=0;.Visible:=True;

// — Работа с пунктом меню «Настройки»
—_OptionInfoAnsver.Enabled:=false;

//Инициация

PriznakExit:=false;

end;

// — Форматирование времени —

Function PrFormatConvert(aa:TPrTime): String;aa.Min<=9
then result:=’0’+IntToStr(aa.Min)result:=IntToStr(aa.Min);aa.Sec<=9 then
result:=result+’:0’+IntToStr(aa.Sec)result:=result+’:’+IntToStr(aa.Sec);;

// Изменение времени.TForm1.DecTime(Var aa:TPrTime; Sender:
TObject): string;aa.Sec=0 thenaa.Min>0 then(aa.Min);.Sec:=59;PrTimeOut(Sender)dec(aa.Sec);:=PrFormatConvert(aa);

end;

// Действия при отсутсвии времени или досрочном ответе

procedure TForm1.PrTimeOut(Sender: TObject);

// — Вывод Стат. инф. о проведени теста —

if NomQuestion=PrKolQuestionTestData then.Enabled:=False;.Visible:=False;
// Отключение клавиш ответов.(‘Ответов (общее кол-воправильных):’+#13+#10

+IntToStr(NomQuestion)+»+IntToStr(PrVAnsverOK));
//PrStatisticsTest(Sender);.Text:= IntToStr(PrVAnsverOK);.Text:=
IntToStr(NomQuestion-PrVAnsverOK);.Text:= IntToStr(NomQuestion);;;

// — Восстановление времени на вопрос —

PrTimeLast:=PrTimeTestData;

// Увеличение номера вопроса на 1

inc(NomQuestion);(Sender);;TForm1.Timer1Timer(Sender:
TObject);

Lbl_Last.Caption:=DecTime(PrTimeLast,Sender);;TForm1.MIOpenFileClick(Sender:
TObject);(Sender);.InitialDir:=ExtractFilePath(Application.ExeName);OpenDialog1.Execute
then_Temp.Lines.LoadFromFile(OpenDialog1.FileName);;TForm1.MIAboutClick(Sender:
TObject);

ShowMessage(‘Разработчик: Хаитов И;’+#13+#10+

‘ ‘+#13+#10+

‘Благодарности’+#13+#10+

‘ ‘+#13+#10+

‘* за разработку блока шифрования и интерфейса:’+#13+#10+

‘ Ikrom;’+#13+#10+

‘ ‘+#13+#10+

‘* за помощь в разработке:’+#13+#10+

‘ }{ak,’+#13+#10+

‘ ‘+#13+#10+

‘http://www.vkontakte.ru/khaitov’+#13+#10+

‘e-mail: ikrom1989_80@mail.ru’);;

// Заполение полей тестаTForm1.PrFillFileds(Sender: TObject);

// Очистка поля
теста.Clear;.Clear;.Clear;.Clear;.Clear;.Lines[0]:=decrypt(Memo_Temp.Lines[2+6*(PrOrderQuestion[NomQuestion]-1)],
30000);.Lines[0]:=decrypt(Memo_Temp.Lines[3+6*(PrOrderQuestion[NomQuestion]-1)],
30000);.Lines[0]:=decrypt(Memo_Temp.Lines[4+6*(PrOrderQuestion[NomQuestion]-1)],
30000);.Lines[0]:=decrypt(Memo_Temp.Lines[5+6*(PrOrderQuestion[NomQuestion]-1)],
30000);.Lines[0]:=decrypt(Memo_Temp.Lines[6+6*(PrOrderQuestion[NomQuestion]-1)],
30000);_NomQuestion.Caption:=decrypt(IntToStr(NomQuestion), 30000);

// Управление полосой прокрутки в полях теста

if MQuestion.Lines.Count>=3 then
MQuestion.scrollbars:=ssVertical else
MQuestion.scrollbars:=ssNone;MV1.Lines.Count>=3 then
MV1.scrollbars:=ssVertical else MV1.scrollbars:=ssNone;MV2.Lines.Count>=3
then MV2.scrollbars:=ssVertical else
MV2.scrollbars:=ssNone;MV3.Lines.Count>=3 then MV3.scrollbars:=ssVertical
else MV3.scrollbars:=ssNone;MV4.Lines.Count>=3 then
MV4.scrollbars:=ssVertical else MV4.scrollbars:=ssNone;;

// Пункт из меню «Начать тестирование»

procedure TForm1.MITBeginClick(Sender: TObject);, i, j: byte;

// Проверка был ли открыт файл с тестом

if Memo_Temp.Lines.Count<4 then(‘Откройте файл теста’);;

end;

// — Узнаем данные о тесте (кол. вопросов и т.д.) —

PrGetDataTest(Sender);:=PrTimeTestData;.Min:=PrKolQuestionTestData
*PrTimeTestData.Min

+PrKolQuestionTestData *PrTimeTestData.Sec div 60;.Sec:=PrKolQuestionTestData
*PrTimeTestData.Sec mod 60;

// — Очистка произвольного порядка вопроса —

for i:=1 to 255 do

PrOrderQuestion[i]:=0;

tempNomQuestion:=0;

// — Выбор вопросов в случайном порядке —

while tempNomQuestion<PrKolQuestionTestData
do;:=1+random(PrSymKolQuestionTestData);j:=tempNomQuestion+1 downto 1
doPrOrderQuestion[j]=i then:=0;;;not (i=0)
then[tempNomQuestion+1]:=i;(tempNomQuestion);;;(Sender);

// Заполнение полей
формы.Caption:=(Memo_Temp.Lines[0]);_FQuestion.Caption:=PrFormatConvert(PrTimeFull);_Last.Caption:=PrFormatConvert(PrTimeLast);:=1;.Enabled:=False;.Enabled:=True;.Visible:=True;.Visible:=True;.Enabled:=True;

// — —_OptionInfoAnsver.Enabled:=True;;

// Нажатие кнопки с вариантом ответа

procedure TForm1.PrClickButton(Sender: TObject);

// — Проверка на правильный ответ на ворос —

if
StrToInt(decrypt(Memo_Temp.Lines[7+6*(PrOrderQuestion[NomQuestion]-1)],30000))=(Sender
as TButton).Tag ThenMI_OptionInfoAnsver.Checked then
ShowMessage(‘Правильно’);(PrVAnsverOK);if MI_OptionInfoAnsver.Checked then
ShowMessage(‘Неправильно’);(Sender);;TForm1.MIExitClick(Sender:
TObject);;;TForm1.MI_OptionInfoAnsverClick(Sender: TObject);:
string;PrPasswordTestData<>» then
begin.ShowModal;PasswordDlg.Password.text=PrPasswordTestData then begin_OptionInfoAnsver.Checked:=
not MI_OptionInfoAnsver.Checked;.Password.text:=»;;;.Password.text:=»;

// — процедура возращает данные из теста —

procedure TForm1.PrGetDataTest(Sender: TObject);_String:
string;: boolean;: string;, b2:boolean;, j : byte;_String:=decrypt(Memo_Temp.Lines[1],
30000);

///ShowMessage(Temp_String);

// — Пароль —i:=1 to length(Temp_String)
do((Temp_String[i]=’ ‘)and not EndFor) thenj:=i+1 to length(Temp_String)
do((Temp_String[j]=’ ‘)and not EndFor) theni+1=j then:=»:=copy(Temp_String,i+1,j-i-1);:=true;

end;

// — Время на 1-н вопрос (мин) —

i:=pos(‘:’,Temp_String);Temp_String[i]<>’ ‘
do(i);;.Min:=StrToInt(copy(Temp_String,i+1,pos(‘:’,Temp_String)-i-1));

// — Время на 1-н вопрос (сек) —

PrTimeTestData.Sec:=StrToInt(copy(Temp_String,pos(‘:’,Temp_String)+1,length(Temp_String)-pos(‘:’,Temp_String)));

// — Кол-во тестируемых вопросов
—:=StrToInt(copy(Temp_String, pos(‘|’,Temp_String)+1,(‘
‘,Temp_String)-pos(‘|’,Temp_String) -1));

// — Суммарное количество вопросов
—:=StrToInt(copy(Temp_String, 1,pos(‘|’,Temp_String) -1));;

//Добавил, возможно потом количество попыток можно довести до 3

// пока сразу закрытие

// срабатывает onClose,
а там еще один пароль — и все, сразу

// зовет преподавателя, а тот делает правильные выводы

{ if PrPasswordTestData<>» then

b1:=(Inputquery(‘Введите пароль’, ‘Пароль’, Password));

if ((b1=false)and (Password<>PrPasswordTestData)) or

((b1=true)and (Password<>PrPasswordTestData)) or

((b1=true)and (Password=PrPasswordTestData)).close;
}PrPasswordTestData<>» then begin.Caption:=’Получение
доступа к тесту’;

PasswordDlg.ShowModal;PasswordDlg.Password.text<>PrPasswordTestData
then begin.Password.text:=»;:=true;.close;;.Password.text:=»;;

//TForm1.FormClose(Sender: TObject; var Action: TCloseAction);:
string;

{ if PrPasswordTestData<>» thenInputQuery(‘Введите
пароль’, ‘Пароль’, Password)=true and (Password=PrPasswordTestData)

///MI_OptionInfoAnsver.Checked:= not
MI_OptionInfoAnsver.Checked;:= caFreeAction := caNone; }(PriznakExit=true) then
begin(‘Неверно задан пароль на доступ к тесту ! Программа завершает работу !’);

Action
:= caFree;

end;(PrPasswordTestData<>») and (PriznakExit=false)
then begin.Caption:=’Закрытие программы тестирования’;

PasswordDlg.ShowModal;PasswordDlg.Password.text=PrPasswordTestData
then begin.Password.text:=»;:= caFree endbegin Action := caNone;
PasswordDlg.Password.text:=»;;;.Password.text:=»;;

//TForm1.MITEndClick(Sender:
TObject);PrPasswordTestData<>» then
begin.ShowModal;PasswordDlg.Password.text=PrPasswordTestData then
begin(Sender);.Password.text:=»;;;.Password.text:=»;.Unit3;Windows, SysUtils,
Classes, Graphics, Forms, Controls, StdCtrls, Buttons;= class(TForm): TLabel;:
TEdit;: TButton;: TButton;

{ Private declarations }

{ Public declarations };: TPasswordDlg;Unit1;

{$R *.dfm}.uEncrypt;Decrypt(const S: AnsiString; Key: Word):
AnsiString; stdcall; ///расшифроватьEncrypt(const S:
AnsiString; Key: Word): AnsiString; stdcall; ///зашифровать= 52845;= 22719;Decode(const S: AnsiString):
AnsiString;: array[Char] of Byte = (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

, 55, 56, 57, 58, 59, 60, 61, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2,

, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,

, 21, 22, 23, 24, 25, 0, 0, 0, 0, 0, 0, 26, 27, 28, 29, 30,

, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45,

, 47, 48, 49, 50, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

);: LongInt;Length(S) of

::= Map[S[1]] + (Map[S[2]] shl 6);(Result, 1);(I, Result[1],
Length(Result));

::= Map[S[1]] + (Map[S[2]] shl 6) + (Map[S[3]] shl
12);(Result, 2);(I, Result[1], Length(Result));

::= Map[S[1]] + (Map[S[2]] shl 6) + (Map[S[3]] shl 12) +

(Map[S[4]] shl 18);(Result, 3);(I, Result[1],
Length(Result));PreProcess(const S: AnsiString): AnsiString;: AnsiString;:=
S;:= »;SS <> » do:= Result + Decode(Copy(SS, 1, 4));(SS, 1, 4);InternalDecrypt(const
S: AnsiString; Key: Word): AnsiString;: Word;: Word;:= S;:= Key;I := 1 to
Length(Result) do[I] := Char(Byte(Result[I]) xor (Seed shr 8));:= (Byte(S[I]) +
Seed) * Word(C1) + Word(C2);Decrypt(const S: AnsiString; Key: Word):
AnsiString;:= InternalDecrypt(PreProcess(S), Key);Encode(const S: AnsiString):
AnsiString;: array[0..63] of Char = ‘ABCDEFGHIJKLMNOPQRSTUVWXYZ’ +

‘abcdefghijklmnopqrstuvwxyz0123456789+/’;: LongInt;:=
0;(S[1], I, Length(S));Length(S) of

::= Map[I mod 64] + Map[(I shr 6) mod 64];

::= Map[I mod 64] + Map[(I shr 6) mod 64] +[(I shr 12) mod
64];

::= Map[I mod 64] + Map[(I shr 6) mod 64] +[(I shr 12) mod
64] + Map[(I shr 18) mod 64];PostProcess(const S: AnsiString): AnsiString;:
AnsiString;:= S;:= »;SS <> » do:= Result + Encode(Copy(SS, 1, 3));(SS,
1, 3);InternalEncrypt(const S: AnsiString; Key: Word): AnsiString;: Word;:
Word;:= S;:= Key;I := 1 to Length(Result) do[I] := Char(Byte(Result[I]) xor
(Seed shr 8));:= (Byte(Result[I]) + Seed) * Word(C1) + Word(C2);Encrypt(const
S: AnsiString; Key: Word): AnsiString;:= PostProcess(InternalEncrypt(S, Key))

end;.

Источник

озможность ввода, изменения данных и их удаления;

·в программе должен быть удобный понятный и интерфейс;

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

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

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

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

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

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

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

2. Проектирование программного обеспечения

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

У каждого программного продукта существует свой жизненный цикл (ЖЦ). ЖЦ — это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПП и заканчивается моментом полного изъятия ПП из эксплуатации. Современный рынок программного обеспечения требует, чтобы выпуск программ был быстрым, а его дальнейшая эксплуатация — долговременной и надежной. Для достижения этого необходима хорошая организация и тщательное планирование всего жизненного цикла программного продукта. Жизненный цикл программ состоит из нескольких этапов: Анализ предметной области, проектирование, реализация, анализ и тестирование, эксплуатация.

В настоящее время широкое распространены 2 модели жизненного цикла:

. Каскадная

. Спиральная

Каскадная

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

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

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

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

Преимуществами каскадной модели являются:

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

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

·Удобна для ПП, где уже в начале достаточно полно сформулированы все требования.

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

Спиральная

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

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

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

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

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

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

Преимущества:

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

От этапа к этапу можно переходить до завершения работ на предыдущем этапе.

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

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

2.2 Фаза проектирования

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

На фазе проектирования происходит:

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

Внешние спецификации включают в себя:

внешние интерфейсы;

функциональное наполнение, видимое пользователю;

взаимодействие между процессами;

форматы файлов;

Внутренние спецификации включают в себя:

реализация интерфейсов;

реализация функционального наполнения;

внутренние структуры данных;

описание алгоритмов;

внутренняя обработка ошибок.

.План тестирования. Данный план работает по следующим пунктам:

структура и среда тестовой системы;

методология тестирования;

— периодичность тестирования.

.План информационной разработки.

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

·SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

·DFD (Da

Источник