 |
Как создается программное обеспечение
|
|
|
|
Как создается ПО
Обычно процесс разработки ПО включает (официально или неофициально) следующие основные этапы:
- идею;
- требования;
- план и график;
- архитектуру;
- конструирование;
- проверку.
Эти этапы изображены на рисунке.
Обратите внимание на то, что они изображены в виде пересекающихся эллипсов и круга. Процесс разработки ПО
- это не ряд последовательных, четко отделенных друг от друга шагов, совершая которые, вы не сможете вернуться назад. Реальные проекты допускают возвращение назад к истокам. Вы работаете над этапом до тех пор, пока не появится необходимость перейти к следующей фазе или вернуться к предыдущей.
Например, не удается определить все требования к ПО еще до того, как вы приступите к созданию архитектуры. Вы определяете лишь основные из них, а затем переходите непосредственно к проекту. Поступая так, можно вернуться назад и прояснить или уточнить некоторые показатели.
Замысел идеи
Идея возникает в результате наблюдений, вдохновения, опыта или проблем в работе. Это основа будущей разработки. Затем уже обдумываются сроки и ресурсы, необходимые для превращения идеи во что-то реальное, т.е. начинается процесс планирования и составления графика.
Определение требований
Требования определяются при обдумывании замысла. Формируется группа по разработке проекта, чтобы выяснить его масштаб, определить список функций, пределы и ограничения во времени и установить иерархию требований по степени важности. Планирование проекта и создание графика
План определяет, как выполнить проект в соответствии с требованиями, определившимися на начальном этапе разработки. Составив план, можно разработать примерный график выполнения проекта, чтобы учесть и сроки.
|
|
|
Однако никогда не следует жестко придерживаться сроков, установленных на первом этапе. Такой график необходим, чтобы проверить, уравновешивают ли друг друга функции приложения и существующие ограничения, такие, как, например, предельный срок завершения проекта, которые на этой стадии еще не конкретизированы.
Создание архитектуры
Не существует одного-единственного способа разработки ПО, так же как не существует единственного метода проектирования домов. Существуют определенные требования к строительству и непреложные физические законы, а в пределах их действий возможны любые варианты. Если возможности практически не ограничены, как архитектор может разобраться, с чего начать, или убедиться, что проект полностью закончен? Здесь-то и нужна методика. Методика - не поваренная книга, руководствуясь которой вам нужно смешать конкретные ингредиенты и получить в результате готовую разработку. Методика л ишь определяет общее направление, следуя которому вы создаете разработку, опираясь на свои опыт и знания.
Методика создания объектно-ориентированной архитектуры называется GUIDS (произносится «гайдз»): от Goal - User - Implementation - Data - Strategy (цель - пользователь - реализация - данные - стратегия). Она состоит в следующем:
- для разработки высокоуровневого проекта приложения внимание концентрируется на целях, которые определены на этапе формулирования требований. Здесь вы работаете с потенциальным пользователем, определяя набор объектов реального мира, их свойства и поведение;
- при проектировании пользовательского интерфейса особое внимание уделяется требованиям и специфическим целям пользователей. Это позволяет определить, как приложение будет выглядеть и как пользователь будет с ним взаимодействовать;
- при проектировании программной реализации выясняются детали структурирования приложения, а объекты, определенные при проектировании основных объектов, преобразуются в классы;
|
|
|
- при проектировании данных определяются способы организации данных и доступа к ним;
- стратегия определяет подход, который будет использоваться при создании приложения. Это различные соглашения и стандарты программирования, управление конфигурацией, методика тестирования, а также план и график реализации.
На стадии создания архитектуры вы решаете, как части будущего приложения будут взаимодействовать друг с другом и с пользовательским интерфейсом. В результате может получиться документ не в одну страницу, что и определит высокоуровневую документацию проекта.
Чтобы опробовать некоторые идеи проекта, часто создается модель или прототип.
Начало конструирования
Создание архитектурного проекта - эскиз вашего приложения. Если приложение простое, то можно просто сесть за компьютер и начать создание форм и кода на VB. Если приложение сложное, то каждому программисту в команде поручается набор объектов и выдается архитектурный проект с заданием создать формы и код на VB для реализации этих объектов.
Начало проверки
После того, как часть работы выполнена, начинается проверка. Это может быть детальная проверка кода, тестирование компонентов, их интеграции, а также всей системы. Цель проверки - обнаружение ошибок и других недочетов кода ранней стадии разработки. Это позволит исправить ошибки и неполадки до того, как они превратятся в серьезную проблему.
В случае несложного проекта написанный код тут же вызывается на экран и тестируется. Если проект сложен требуются более интенсивные проверки, в которых участвую сразу несколько программистов. Необходимо также независимое тестирование компонентов (так называемое бета-тестирование, когда какая-то часть приложения или все приложение сразу отдается на тестирование людям, которые его не разрабатывали), их интеграции, всей системы и т.д. После последней проверки программу можно считать завершенной.
Поддержка приложения
После того, как приложение завершено, оно требует поддержки. Поддержка включает в себя исправление ошибок, улучшения, изменения в соответствии с изменившимися правилами бизнеса и любые другие модификации. Они тоже будут выполняться в соответствии с описанным выше процессом разработки программы. Выдвигается идея изменения, определяются требования к нему, планируется модернизация, для нее назначаются сроки, разрабатывается архитектура, изменение конструируется и проходит новое тестирование.
|
|
|
Литература
1. Афанасьев А.И., Карпиков И.И. и др. Электромагнитная безопасность при работе с компьютерной техникой. - М.: Циклон-Тест, 2008. - 112 с. 2.
2. Беспалько В.П. Образование и обучение с участием компьютеров (педагогика третьего тысячелетия). - М.: Московский психолого-социальный институт; Воронеж: МОДЭК, 2002. -352 с. 3.
. Беспалько В.П. Основы теории педагогических систем. - Воронеж: ВГУ, 2007. - 304 с. 4.
. Битянова М. Свободная деятельность / Психолог (приложение к газете 1 сентября). - 2000. - 47.5.
. Бовин А.В. Новые функции КВТ // Информатика и образование. - 2007. - 1. - С. 94-96.6.
. Бойко Г.М., Пак Н.И. Информационная среда школы открытого типа в области управления и построения учебного процесса // Открытое образование. - 2001. - 2. - С. 36-38.7.
. Борисова Н.В. От традиционного через модульное к дистанционному образованию. - М. - Домодедово: ВИПК МВД России, 2009. - 174 с. 8.
. Бочкин А.И. Методика преподавания информатики. - Минск: Вышэйшая школа, 1998. -431 с. 9.
. Воронин Ю.А. Компьютеризированные технологии в процессе подготовки учителя // Педагогика. - 2003. - 8. - С. 53-59.10.
. Воронин Ю.А. Перспективные средства обучения. Монография. - Воронеж: ВГПУ, 2000. -124 с. 11.
. Воскресенский А.Л., Петропавловская Ю.А., Хлебников Б.И. Об оснащении компьютерных классов // Информатика и образование. - 2007. - 2. - С. 72-79.
|
|
|
