Главная цель анализа– определить, какие действия должна выполнять будущая система (например, требование ограниченного доступа к данным)
На этапе проектирования создается структура системы программного обеспечения. Хорошо известно, что самой лучшей структурой для больших систем является модульная структура, то есть разделение программы на более мелкие элементы, каждый из которых выполняет только часть общей задачи. Без такой структуры количество технических деталей, которые нужно учитывать при реализации системы, превысило бы возможности человека. Модульная структура также облегчает последующую эксплуатацию системы, поскольку она позволяет при модификации вносить изменения только в конкретные модули.
Этап реализации включает в себя написание программ, создание файлов данных и баз данных.
Этап тестирования связан с этапом реализации, поскольку каждый модуль системы обычно тестируется сразу же после его реализации. В логичной и продуманной системе проверка каждого модуля должна осуществляться независимо от других модулей системы. По мере создания модулей тестирования отдельных компонентов заменяется тестированием всей системы.
Ранние подходы к разработке программного обеспечения требовали строго последовательного выполнения всех этапов. Такой метод разработки в настоящее время называется водопадной моделью, поскольку процесс разработки протекает в одном направлении. Примером альтернативного подхода может служить инкрементная модель проектирования, согласно которой разрабатываемая система программного обеспечения строится последовательными приращениями. Первая система является упрощенной версией конечного продукта с ограниченными функциональными возможностями. После тестирования этой версии и оценки ее будущим пользователем к ней добавляются дополнительные возможности, и она снова тестируется.
Наиболее известным методом проектирования является нисходящее проектирование. Суть его состоит в том, что задача разбивается на небольшие, более легко решаемые подзадачи. В результате применения нисходящего проектирования получается иерархическая система, которую часто можно сразу преобразовать в модульную структуру, соответствующую императивной парадигме программирования.
При восходящем проектировании создание системы начинается с определения отдельных задач системы и обсуждения того, как решения этих задач могут использоваться в качестве абстрактных инструментов для решения более сложных задач.
Разработка открытых программных продуктов. Этот метод в течение многих лет использовался компьютерщиками энтузиастами, а теперь признан законной методикой разработки программного обеспечения. В действительности, эта методика представляет собой разновидность эволюционного макетирования, но в отличие от традиционного подхода макетирование осуществляется открыто. Эта методика называется разработкой с открытым исходным текстом.
В некотором смысле разработка открытых программных продуктов является расширением бета-тестирования (рассмотрено ниже), но при этом испытатель бета-версии может модифицировать ее и сообщить о сделанных изменениях, а не просто о возникших проблемах, как при обычном бета-тестировании. Процесс создания открытых программных продуктов состоит из следующих этапов: автор пишет первоначальную версию программы (обычно выполняющую необходимые ему действия) и размещает исходный код и документацию в Интернете, откуда ее могут скачать другие программисты. Поскольку пользователи имеют в своем распоряжении исходный код и документацию, они могут изменять и дополнять программу согласно своим потребностям или исправлять обнаруженные ими ошибки. Затем они сообщают о сделанных изменениях автору, который заносит их в версию продукта, размещенную в Интернете. Таким образом, эта новая расширенная версия становится доступной для дальнейших модификаций. Практика показывает, что за неделю пакет программного обеспечения может изменяться несколько раз.
Поскольку действия разработчиков открытых систем программного обеспечения не согласованы и они не получают за свою работу никакого вознаграждения, может показаться, что они недостаточно мотивированы, чтобы создать высококачественную систему программного обеспечения. Однако опыт показывает обратное. В качестве примера можно привести операционную систему Linux, признанную самой надежной операционной системой из всех имеющихся в наличии. На самом деле, Линуса Торвальда, создателя этой операционной системы, можно считать родоначальником разработки отрытых программных продуктов, поскольку он руководил разработкой Linux именно с помощью этой методики.
Одной из причин, по которым разработка отрытых программных продуктов не применяется широко, является сложность установления права собственности на конечный продукт, ведь разработка открытых программных продуктов означает, что это программное обеспечение должно быть всеобщим достоянием и находиться в открытом доступе.
Другая трудность создания отрытых исходных текстов заключается в том, что руководителям такого проекта, привыкшим работать в деловом обществе, трудно принять стиль работы с рискованным финансированием, который необходим для успешной разработки открытого программного обеспечения. Условием такого метода разработки программного обеспечения является свободная, ничем не ограниченная работа программиста, которым управляет энтузиазм, желание выразить себя и чувство удовлетворения и гордости за проделанную работу. Однако часто руководители проектов своим чрезмерным контролем подрывают энтузиазм разработчиков. Например, руководитель может удержать некоторые части системы, чтобы установить право собственности, но разработка открытых программных продуктов подразумевает, что программист может скачать, использовать и модифицировать согласно своим потребностям всю программную систему.
