dedo1991 Ответов: 1

Жизненный цикл разработки программного обеспечения (как это сделать: требования и дизайн)


Привет,

Этапы СДЛ :

1. Требования -&ГТ; 2. Дизайн -&ГТ; 3. Реализация -&ГТ; 4. Тестирование -&ГТ; 5. Релиз

Я не уверен в первых 2 этапах этого пошагового подхода. Итак, ниже приведено описание того, как я буду это делать.

Чтобы получить требования, мы просто используем UML-диаграммы.
На стадии проектирования мы просто разрабатываем прототип низкой точности (ручка и бумага + описание различных элементов и кнопок), а затем прототип высокой точности (какой-нибудь инструмент прототипирования, такой как Axure или даже веб-формы с функцией перетаскивания и HTML/css-кодом).


Правильно ли это? Любые комментарии или предложения приветствуются.

1 Ответов

Рейтинг:
10

Sergey Alexandrovich Kryukov

Я дам вам только короткий ответ. Это не самое подходящее место для полного ответа на этот вопрос. Метод разработки-это большая тема и предмет обсуждения, часто жаркого.

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

Самый первый пункт, вероятно, начало, а не "требования". Эта последовательность уже чрезмерно упрощена с точки зрения набора элементов, но это не самая большая проблема. Что еще более важно 1) эти предметы на самом деле перекрытие; даже у вас на стадии №5 могут быть некоторые изменения требований (№1), что естественно, потому что к концу работы люди лучше понимают требования; неготовность к таким изменениям-одна из больших ошибок; название стадии просто указывает, где находится максимум определенной активности; 2) стадии фактически приходят в движение. итерационные циклы после каждой итерации люди снова и снова возвращаются к циклам требований, проектирования и другим циклам, и, наконец, этот процесс сходится.

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

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

Тем не менее, если вы правильно прочтете эти книги, они могут быть вам полезны. Они могут научить вас:
1) серьезно относиться к методу развития, 2) определить некоторые хорошо сформулированные и очень фундаментальные принципы и следовать им тщательно и точно.

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

Будьте осторожны.

[РЕДАКТИРОВАТЬ]

См. также мой прошлый ответ: Советы по архитектурной схеме[^].

Тем не менее, не рассматривайте и эти рекомендации как универсальные или абсолютные. Создайте свой собственный метод, анализируя свои цели и обсуждая это с командой.

—СА