软件开发过程模型 [英] Process Model for Software Development

问题描述

嗨！！！谁能帮我解决我的问题?在本文中，4d模型不适用于本研究的开发过程.我们在论文中排在3位.我们只开发43天的申请.我们的小组成员说，4d流程模型需要每个阶段的文档，但是突然之间我们没有文档化所有内容.小组成员建议我们更改流程模型.如果我们将使用RAD流程开发，那么它也不适用，因为它在一个团队中包含6个以上的成员.

谢谢您的帮助...

Hi!!! Can anyone help me fix my problem? In our thesis, 4d model is not applicable for the development process of our study. We were group by 3 in our thesis. We develop application for 43 days only only. Our panelist said that 4d process model needs documentation for every phase but suddenly we did not document everything. Our panelist recommend us to change our process model. If we will use RAD process development it is not also applicable to use because it contains more than 6 members in a team.

Thank you for your help...

推荐答案

我假设我想要一个不同的开发过程.
不知道自己到底在做什么，很难说，因为不同的情况适合于不同的过程.

我建议您转向敏捷过程:

I''m assuming you want a different development process.
Without knowing what you are doing exactly, it is difficult to say, because different situations are suited to differenct processes.

I suggest you move to an agile process:

1. 它们很流行，并且在您的简历上看起来很好，尤其是如果您在其他地方使用了正式"过程
2. 研究表明，它们可以更快地产生更好的结果(尤其是适用于第3点的情况)
3. 在问题未明确定义的情况下(它们在研究项目中属于这种类别)，它们可以很好地发挥作用.
4. 一些研究表明，它们不适用于大型团队:您不要属于此类别

1. They are popular and will look good on your CV, especially if you have used "formal" processes elsewhere
2. Studies show they produce better results quicker (especially where point 3 applies)
3. They work well in a situation where the problem is not well defined (as you are doing a research project, you fall under this category)
4. Some studies show they do not work well for large teams: you don not fall into this category

从我所能发现的4D似乎暗示的正式"方法(范围->设计->实现->测试->发布)是有问题的.对于任何重要的系统来说，正确地设计都是很难的，双重原因是，对于研究系统而言，所有其他步骤都取决于该系统.这种方法的主要好处"是管理者认为他们有一个具体的计划(但是由于计划的困难，这常常是有缺陷的).这也是人们通常被称为正确"方法的东西，因为它看起来很严格.

我建议您选择 XP(极限编程)作为您的第一选择:它适用于小型小组，响应迅速，没有太多的文档拖动".根据您的小组的帮助/知识/灵活性，他们可能不接受它，因为如果他们不了解XP的正确性，他们可能会认为这只是混乱.

另一种方法是 Scrum ，由于它具有一些轻量级的计划(增加了文档拖曳力，但是与正式方法相比没有任何东西)，因此可以更轻松地出售给面板.请参阅 XP和Scrum之间的比较 [

"Formal" methods (Scope --> design --> implement --> test --> release), which is what 4D seems to suggest from what I could find of it, is problematic. Getting the design right is hard for any significant system is hard, doubly so for a research system all other steps are predicated on it. The main "benefit" of this approach is that managers think they have a concrete plan (but often this is flawed due to the difficulty of planning). It is also what people are normally taught as the "correct" methodology because it looks strict.

I suggest you look up XP (eXtreme Programming) as your first choice: it works well with small groups is responsive and doesn''t have much documentation "drag". Depending on how helpful/ knowledgable/ flexible your panel is, they may not accept it as they might think it is just chaos if it they do not understand what XP is properly.

An alternative is Scrum, it will be easier to sell to your panel as it has some light planning in (with increased documentation drag, but nothing compared to formal methods). See A comparison between XP and Scrum[^].

In the case of either XP or Scrum it is important to understand what the methodology is trying to achieve, and apply it thoroughly. Pair programming may seem slower on the face of it, but it is quicker. Unit tests must be used, they will save work on a project that is weeks long even if they seem unecessary in the outset, and goe some way to replace documentation if done well.

All this is my opinion, others will hopefully give a different viewpoints so you can select the one you think appropiate.

这篇关于软件开发过程模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！