软件开发生命周期（如何做：要求和设计） [英] Software Development Life Cycle (How to do : Requirements and Design)

问题描述

SDL的各个阶段：



1.要求 - > 2.设计 - > 3.实施 - > 4.测试 - > 5.发布



我不确定这一步一步的前两个阶段。下面是我将如何去做的描述。



为了得到这些要求，我们只需使用UML图。

在设计阶段，我们只开发低保真原型（笔和纸+各种元素和按钮的描述），然后是高保真原型（像Axure的一些原型设计工具，甚至是具有拖放功能和html / css代码的网页形式）。





这是对的吗？欢迎任何意见或建议。

Hi,

The phases of SDL :

1. Requirements -> 2. Design -> 3. Implementation -> 4. Testing -> 5. Release

I am not sure about the first 2 stages of this step by step approach. So below is the description of how I would go about doing it.

In order to get the requirements we simply use the UML diagrams.
In design stage we just develop a low fidelity prototype (pen and paper + description of various elements and buttons) and then high fidelity prototype (some prototyping tool like Axure or even web forms with drag and drop functionality and html/css code).


Is this correct? Any comments or suggestions are welcome.

推荐答案

我会给你简短的答案。这不是一个完整回答这个问题的好地方。开发方法是一个很大的话题，而且讨论的问题往往很激烈。



我想强调的只是一个方面的问题。您描绘的架构实际上绝不是这种情况。如此严峻的情况可能是人们犯下的最大错误之一。



第一项可能是初始，而不是要求。这个序列在项目集方面已经过度简化，但这不是最大的问题。更重要的是1）那些项目实际上是重叠;甚至你在第5阶段也可能会有一些需求变化（＃1），这很自然，因为在工作结束时人们会更好地理解需求;没有为这种改变做好准备是一个重大错误;阶段的名称仅表示某个活动的最大值; 2）阶段实际进入迭代循环，每次迭代后，人们一次又一次地回到需求，设计和其他循环，最后，这个过程收敛。



您可以阅读其中一些关于不同开发方法的书籍和文章。但是你永远不应该放弃你的现实感和批判性思维，而这反过来需要很多经验。您应该从了解项目目标开始了解您的开发方法。最重要的是，您应该考虑资格，甚至考虑团队成员的品味，文化特征，潜在或实际客户的文化，可用工具和投资可能性。 如果你试图定义你的开发方法不是基于所有这些因素，那将是另一个大错误。



我相信很多并非所有关于该主题的书籍或文章都与伪科学有关，如炼金术。人们在他们做一些项目的时候，根据技术水平，他们个人理解它的方式，有一些经验，但后来他们试图将其概括，对某些原则有些绝对化，但这些原则对他们有用，但实际上并不普遍。



尽管如此，你正确阅读这些书，它们对你有用。 他们可以教你：

1）认真对待开发方法，2）定义一些精心设计的非常基本的原则，并彻底，准确地遵循它们。 />


但他们可能很容易误导你进入：1）遵循本书中的一些严格的原则，而不是分析你当前的目标和情况， 2）认为这个原则是真正的严格的科学，并遵循盲目折叠的公式（我会说，大脑折叠:-)）方式。



小心。







另见我过去的答案：架构图提示 [ ^ ]。



尽管如此，不要将这些建议视为普遍或绝对的。在分析目标时创建自己的方法并与团队讨论。

-SA

I'll give you just the short answer. This is not a good place for a full answer to this question. Development method is a big topic, and a matter of discussion, often heated.

I want to emphasize only on a could of aspect. The schema you depicted is practically never the case. Following such a rigid scenario could be one of the biggest mistakes people make.

Very first item is probably inception, not "requirements". This sequence is already overly simplified in terms of the set of items, but this is not the biggest problem. More importantly 1) those items are actually overlap; even of you stage #5 there could be some requirement changes (#1), which is natural because by the end of the work people understand requirements better; being not ready for such change is one of the big mistakes; the name of the stage merely indicates where is the maximum of certain activity; 2) the stages actually comes in iterative cycles, after each iteration, people get back to requirement, design and other cycles again and again, and finally, this process converge.

You can read some of those many books and articles on different development methods. But you should never loose your sense of reality and critical thinking, which, in turn, requires a lot of experience. You should start understanding of your development methods from understanding of goals of your project. On top of that, you should take into account qualification and even the taste of the team members, cultural features, culture of your potential or actual customers, available tools and investment possibilities. If you try to define your development methods not based on all these factors, it would be another big mistake.

I am sure that many, of not all, books or articles on the topic are somewhat related to pseudo-science, like alchemy. People have some experience based on the level of state of technology at the time they did some projects, the way they personally understood it, but later they tries to generalize it, with some absolutization of some principles which worked for them but are actually not universal.

Nevertheless, it you read those books properly, they can be useful for you. They may teach you:
1) to take development method seriously, 2) to define some well-formulated and very fundamental principles and to follow them thoroughly and accurately.

But they may easily mislead you into: 1) following some rigid principles read from the book, not from analysis of your current goals and situation, 2) thinking that this principles is "real" strict science and following the "formula" in a blind-folded (I would say, brain-folded :-)) way.

Be careful.



See also my past answer: Architecture diagram tips[^].

Nevertheless, don't consider and of those recommendations as universal or absolute. Create your own method as you analyze your goals and discuss this with your team.

—SA

这篇关于软件开发生命周期（如何做：要求和设计）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！