Принцип системности предполагает
выбор содержательных элементов, которые
отвечают требованиям системности и связаны
между собой общей структурой знаний.
Если соблюден принцип системности, то
тестовую программу можно применять не
только для выявления объема знаний, а
также и для оценки качества структуры
знаний испытуемых.
Направленность
тестов. Самыми актуальными в современной
диагностике, являются тесты интеллекта,
личностные тесты и тесты достижений.
С некоторой частью условности, первые
два вида совместно образуют тип «психологического
теста», в то время как последний определяется
как - «педагогический тест».
Проектирование программного продукта
Важной задачей
при проектировании программного
продукта является разработка требований,
или анализ требований к продукту. Определим
понятия «Проектирование», «реализация», «тестирование».
Проектирование — процесс разработки проекта, то есть комплекта документации,
предназначенной для создания определённого
объекта, его эксплуатации, ремонта и ликвидации,
а также для проверки или воспроизведения
промежуточных и конечных решений, на
основе которых был разработан данный
объект. Проектирование — длительный процесс
и включает этапы от подготовки технического
задания до испытания опытных образцов
(А.М.Вендров, 2002).
Реализация
(имплементация) — это та часть процесса,
во время которой программисты собственно
создают программный код продукта (Э.Брауде,
2004).
Тестирование — всеобъемлющая и важная
часть процесса разработки программного
обеспечения. Эта часть процесса заключается
в том, чтобы выявить и решить различные
ошибки. Тестирование применяется для
определения соответствия предмета испытания
заданным спецификациям.
Тестирование — один из разделов диагностики
(А.М.Вендров, 2002).
Программное обеспечение – это продукт интеллектуальной
деятельности, включающий в себя информацию,
выраженную через средства поддержки. Для разработки прикладных
программ важно правильно подобрать и
сочетать методы, средства и технологии
проектирования программного обеспечения.
Разработка
любого программного обеспечения начинается
с анализа требований и постановки задач
проектирования к будущему программному
продукту. В результате анализа технического
задания строится будущая модель программного
продукта.
Какой бы ни был проект разработки программного
обеспечения, он в своем развитии проходит
определенный жизненный цикл – определенная
последовательность этапов и совокупность
действий, в результате которых создается
первая версия продукта. Реалистичная
модель жизненного цикла наиболее упрощает
выполнение проекта и дает гарантии, что
в проекте с каждым последующим этапом
реализуется все больше ранее запланированных
задач.
Основным
нормативным документом, регламентирующим
жизненный цикл программного обеспечения,
является международный стандарт ISО/IЕС
12207 (ISО - Intеrnаtiоnаl Оrgаnizаtiоn оf Stаndаrdizаtiоn
- Международная организация по стандартизации,
IЕС - Intеrnаtiоnаl Еlесtrоtесhniсаl Соmmissiоn - Международная
комиссия по электротехнике). Он определяет
структуру жизненного цикла, содержащую
процессы, действия и задачи, которые должны
быть выполнены во время создания программного
обеспечения (Международные стандарты,
поддерживающие жизненный цикл программных
средств. М., МП "Экономика", 1996).
Структура жизненного
цикла программного обеспечения
по стандарту ISО/IЕС 12207 основывается на
следующих этапах процесса:
- основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение);
- вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
- организационные процессы (управление проектами, создание инфраструктуры проекта, определение.
Для того чтобы приступить к разработке
системы важно иметь четкое описание методологии
разработки, предназначенной к конкретному
проекту.
В результате
выбранных методологий производится выборы конкретных проектных
инструментов и программных средств.
На начальном этапе
разработке, необходимо определиться
с применяемыми программными продуктами,
использующиеся в ходе построения системы.
По мере повышения сложности программных
проектов возрастают требования к эффективности
их реализации. Это тем более важно на
сегодняшний день, когда разработчики
программных обеспечений вовлечены практически
во все нюансы работы предприятий и число
таких специалистов неуклонно растет.
В это же время проведенные
исследования в этой области показывают
нам результаты как минимум половины "внутренних"
проектов разработки программных средств
не оправдывают возложенных на них надежд.
В данных условиях особенно важной и наиболее
главной становится задача оптимизации
всего процесса создания программных
средств с охватом всех его участников
- проектировщиков, тестеров, разработчиков,
служб сопровождения и менеджеров. Управление
жизненным циклом приложений (Application Lifecycle
Management, ALM) рассматривает процесс выпуска
программных средств как непрерывно и
постоянно повторяющийся цикл взаимосвязанных
этапов:
определение требований (Requirements);
проектирование и анализ (Design & Analysis);
разработка (Development);
тестирование (Testing);
развертывание и сопровождение (Deployment & Operations).
Каждый из
этих этапов должен внимательно отслеживаться
и тщательно контролироваться. Правильно
организованная ALM-система позволяет:
сократить сроки вывода продуктов на рынок
(разработчикам необходимо заботиться
лишь о соответствии их программ ранее
выдвинутым требованиям);повысить качество,
гарантируя при этом, что разработанные
приложения будут соответствовать потребностям
и ожиданиям пользователей; повысить производительность
труда (у разработчиков есть возможность
делиться накопленным опытом разработки
и внедрения); ускорить разработку благодаря
интеграции инструментов; уменьшить затраты
на сопровождение, постоянно поддерживая
соответствие между приложением и его
проектной документацией; получить максимальную
отдачу от инвестиций в навыки, процессы
и технологии.
Методологии. Существует множество различных
методологий. Особенно среди них можно
выделить такие методологии как тяжеловесные
и гибкие. Для первых необходимо детальное
и тщательное планирование огромного
объема разработок, большой объем документации,
и этот подход работает - однако до тех
пор, пока не начинаются изменения. Следовательно,
для таких методологий сопротивляться
всяким изменениям абсолютно естественно.
Гибкие же методологии, наоборот, приемлют
изменения.
В отличие
от тяжеловесных, они были разработаны как процессы,
адаптирующие изменения и только остаются
в выигрыше от них, даже в том случае, когда
изменения будут происходить в них самих.
Самыми известными и популярными гибкими
методологиями в настоящее время является
RUP (Rational Unified Process) и XP (eXtreme Programming).RUP и XP
происходят из различных философских
основ. RUP - это система процессных компонент,
методов и техник, которые вы можете применить
в любом конкретном программном проекте.
Предполагается, что пользователь будет
адаптировать RUP.
С другой стороны
XP - более ограниченный процесс, который требует дополнений
для того, чтобы соответствовать более
полному циклу разработки проекта. Именно
эта разница объясняет предпочтения в
сообществе разработчиков программного
обеспечения. Разработчиками крупных
систем рассматриваются RUP в качестве
решения своих проблем, в то время как
разработчики малых систем решение своих
проблем видит в XP. XP это более упрощен,
ориентирован на кодирование процесс,
для небольших проектов. Эта технология
основана на итерациях, которые объединяют
некоторые приемы, в число которых входят
такие как небольшие релизы, простое проектирование,
тестирование и постоянная интеграция.
RUP – это
итеративная методология, которая основана на шести
признанных в отрасли лучших технологиях
(Э. Брауде, 2004). Главной целью RUP является
сокращение рисков. Методология RUP уточнялась
в результате тысяч проектов, которые
выполнялись тысячами клиентов и партнерами
компании Rational.
Разработка
программ имеет такую особенность, что, с одной
стороны, это процесс итерационный, а с
другой - он редко последовательно переходит
от одного этапа к другому. Зачастую бывают
случаи, когда от тестирования разработчикам
приходится переходить назад к проектированию,
потом - к развертыванию, а затем, возможно,
вновь возвращаться на этап определения
требований по мере изменения производственных
потребностей. Кроме того, нужно отметить,
что внутренняя организация процесса,
а главное, распределение функций и ролей
его участников, может сильно варьироваться
в зависимости от корпоративных регламентов
и специфики конкретных проектов.
Первым был
разработан компилятор – Assembler. Следом были разработаны
такие языки программирования как: С, ADA,
FoxPro, Fortran, Basic, Pascal и др. Некоторые из них
были предназначены только для школьников
или обучения, другие были ориентированы
на профессиональных программистов. И
тут начались— какой язык лучше. Некоторые
говорили, что это Pascal, другие утверждали
что С, ну, а кое-кто утверждал, что это
Visual Basic. Этот спор длится уже около 30 лет,
и конца ему не видно. При этом все спорные
вопросы разделились на две части:
- Какой язык самый лучший?
- Что лучше — язык высокого уровня или низкого?
Спор по первому пункту не может
закончиться до сих пор. Каждый пытается
доказать, что его язык программирования
самый мощный, удобный и создает
самый быстрый программный код. Мне
кажется, что этот спор не закончится никогда.
В принципе, такое положение дел устраивает
всех, потому что это своеобразная конкуренция.
Благодаря ей происходит развитие языков
программирования, и мы быстро продвигаемся
вперед.
Следующей ступенью стало объектно-ориентированное
программирование. Язык С превратился
в C++, Pascal превратился в Object Pascal и т. д.
Последней крупной
революцией, происходящей в программировании,
считается переход на визуальное
программирование. Этот переход происходит прямо на наших
глазах. Визуальность дает нам еще более
удобные средства разработки для более
быстрого написания кода, но проигрывает
ООП по быстроте работы. Вот почему многие
начинающие программисты стоят на перекрестке,
не зная, какой язык выбрать. Лидером в
разработке визуальных языков программирования
является Borland, а приверженцем ООП остается
Microsoft. Конечно же, Билл Гейтс пытается
встроить ООП в свои языки, но там оно примитивно
по сравнению с такими гигантами, как Delphi,
или C++ Builder. Это связано с изначальной
неправильной разработкой MFC (Microsoft Foundation
Classes — Основные классы Microsoft), которая
не может работать визуально.
Осталось
только ответить на вопрос: "Какой
язык программирования лучше?" Программисты
уже несколько лет пытаются ответить на
этот вопрос, но окончательного решения
вынести не могут. Даже у того же Visual C++
от Microsoft есть свои плюсы. Да, как это ни
странно, положительные стороны есть у
всех. Вопрос остается только за тем, какие
программы будут создаваться? Здесь можно
дать примерно такую градацию:
- Если вы будете писать базы данных, программы общего значения или утилиты, то ваш язык Delphi или C++ Builder.
- Если это игры, то желательно Visual C++ или Watcome С плюс знание Assembler. Но это не значит, что нельзя использовать Delphi или C++ Builder. В этих средах вы потеряете не намного больше в скорости работы, поэтому в большинстве игр можно не обращать внимания на эту потерю. Если правильно использовать свои знания, то и на самом медленном и слабом языке программирования можно создать шедевр.
- Если это будут драйверы и работа с "железом", где критичен размер файла, ваш язык — чистый С или Assembler.
И все же большую
массу программ занимают утилиты
и базы данных. А тут визуальность
необходима, если вы хотите оказаться впереди. Визуальные
языки будут жить и за ними будущее.
Свою тестовую
программу я разработала в
среде разработки Delphi фирмы Borland. Концепция
Delphi1 была реализована приблизительно в конце 1994
года, когда вышла первая версия среды
разработки. В основу этого программного
продукта легли концепции объектно-ориентированного
программирования (ООП) на базе языка
Object Pascal и визуального подхода к построению
приложений. Среда разработки Delphi представляет
ниже перечисленные новые свойства и усовершенствования.
Новые расширения
языка. В Delphi в язык Object
Pascal включены динамические массивы,
возможности обработки переполнения,
установка значения параметров по умолчанию,
и многое другое. Менеджер Проекта.
Новый менеджер проекта позволяет
Вам объединить проекты,
работающие вместе в одной проектной
группе. Это позволяет
Вам организовать и работу взаимозависимых
проектов, таких как однозадачные
и многозадачные приложения или DLL, и совместную
работу исполняемых программ.
Новый проводник. Новый проводник содержит
такие усовершенствования как выполняемые
классы, навигацию по модулям, и браузер
кода. Проводник кода позволяет проще
создавать классы, автоматизируют
многие из шагов. Проводник позволяет
быстрое перемещение между файлами
модуля, а так же между интерфейсом
и реализацией. Использование символа
Tooltip, дает возможность просматривать
информацию об объявлении любого
идентификатора, затем используя
браузер код, можно перейти к его объявлению.