你应该花多少时间在设计上？ [英] How much time should you spend on design?
问题描述
当我看到其他人在论坛上我们的专家表达了软件设计不需要的意见时，我有点担心，他们首选的开发设计方法是开始编码，让程序发展所需的功能。
我关心的不是这个方法，每个人都在某个时候使用这种设计方法（我重新调查），即使它只是用于调查方法来执行某些操作的测试床。然而，我得到的印象是这是这个人使用的唯一设计方法。
有很多设计方法，但只是跳进去编写代码可能是正确的我创建一个商业软件的方法列表的底部（在我的写入测试床列表的顶部，生命周期<1个月左右）。
到目前为止，你可能想知道我使用的是什么了不起的设计方法。好吧，我不能说出一个（我从来没有擅长记住无用的信息），但我做的一些事情是
- 决定并记录系统的各个部分将如何进行
- 记录通信中使用的协议标准或编写协议文件
- 记录班级结构，相互沟通，特别注意时间和避免竞争条件。
- 如果项目使用OOP
- 决定程序数据的存储方式
- 记录用于数据存储的数据（或表）结构
- 设计密钥类或模块详细说明，当我开始主程序设计时，它们就可以使用了。
- 写出任何将用作程序艺术的状态机
- Decide and record how various parts of the system are going to communicate with each other taking particular note of timing and avoidance of race conditions.
- Either record the standard of the protocol to be used in communication or write a protocol document
- Record the class structure if the project uses OOP
- Decide how program data will be store
- Record the data(or table) structures used for data storeage
- Design key classes or modules in detail so they are ready to be used when I start on the main program design.
- Write out any state machines that will be used as art of the program
I was mildly concerned when I saw else where on the forum on of our experts express the opinion that software design saw not required and their prefered design method of development was to just start coding and just let the program evolve the features required.
My concern is no so much the method, everyone uses this design method at sometime (I recon) even if it is just for a test bed investigating the method to perform some operation. However the impression I got was this was the only design method this person used.
There are a lot of design methodologies out there but just jumping in there and writing the code is probably right at the bottom of my list of ways to create a comercial piece of software (and at the top of my list of writing test beds with a lifetime of < 1 month or so).
By now you probably want to know what amazing design methodology I use. Well I can''t name one (I have never been good at remembering useless information), however some of the things I do are
推荐答案
我有有一件事我已经学会了它的设计，设计，设计。特别是在数据库方面。
如果你试图创建一个数据库而不会锁定数据库所需的表的设计和结构，你只需要为你自己以后。有时很多工作。在结构化和OO语言中，您有时可以使用adhoc方法。它不是最有效的，但有时可以基于时间限制最方便的方法，但我绝不会建议使用数据库。
数据库设计从表结构开始，每个查询，表单和报告都依赖于此。即使更改表中的字段名称，也可能会对查询，表单，报表和VBA代码进行大量更改。数据库设计的第一条规则是设计。根据数据库中所需的报告以及需要输入的数据条目来计算用户需求，并对实现此目的所需的数据进行反向工程。然后规范化数据，以便您获得良好的表格设计结构，不仅可以满足这些要求，而且可以适应未来的要求和增强。
所以回答标题中的问题...
在平均项目中，我将花费2周的时间进行需求收集和结构设计，4/5周的时间来设计表格和报告以及系统测试，1周的文档和用户测试和调试的半个星期。
假设一个10周的项目是项目花费在设计上的五分之一。
Mary
I there is one thing I''ve learned the hard way it''s DESIGN, DESIGN, DESIGN. Particularly when it comes to databases.
If you try to create a database without locking down the design and structure of the tables you are going to need for the database you are only creating work for yourself later on. Sometimes a lot of work. In structured and OO languages you can sometimes imploy the adhoc method. It''s not the most efficient but can sometimes based on time contraints the most convenient method but I would never recommend doing it with databases.
A database design starts with the table structure and every query, form and report is dependent on this. Even the changing of a field name in a table can cause you to make numerous changes to queries, forms, reports and VBA code. The first rule of database design is to DESIGN. Work out your user requirements based on the reports they require from the database and the data entry they need to put in and reverse engineer the data that is required to achieve this. Then normalise the data so that you achieve a good table design structure that can not only deliver on these requirements but is adaptable to future requirements and enhancements.
So to answer the question in the title ...
On an average project I would spend 2 weeks on requirements gathering and structural design, 4/5 weeks on designing the forms and reports and system testing, 1 week on documentation and 1/2 weeks on user testing and debugging.
Assuming a 10 week project that is 1 fifth of the project time spent on design.
Mary
很明显你是从OO的角度进行设计的，在这种情况下，我会首先将用例描述为发现用户需求的第一步。 />
基于此，对象模型，方法和属性将不断发展。
就个人而言，我更传统。在开发Access数据库时的设计。我首先收集所需的输出（报告和表单），并通过跟踪根属性我开始将它们分组到用户的数据模型中。
（未规范化，但使用用户理解的定义。 ）
我使用粗鲁的模型来制作规范化的数据模型，并在此过程中我验证（使用用户模型）定义以获得声音规范化数据模型。
最后，我开始围绕找到的基本创建表单。表并使用Object / Action原则。 （我显示所有出现的主窗体，以便用户可以过滤他需要的设置）并添加动作按钮，如[添加]，[更新]，[删除]，[打印]等。
这将涵盖约60/70％的需求，并给我一个模型来调整用户并添加额外的要求。 （原型的种类）
最后，我通过添加最后的特定功能并创建用户指南来完成数据库。
设计更多或在整个过程中不那么连续，需要大约25％，数据库设计和表格/报告等。将占用大约50％，最后25％用于测试和文档（用户指南）。
Nic; o）
It''s obvious you''re designing from the OO perspective and in such a case I would start with describing Use Cases as first step to discover the users needs.
Based on that the objectmodel, methods and properties will evolve.
Personally I''m more "traditional" in design when developing Access databases. I start with collecting the needed output (reports and forms) and by tracing the root attributes I start grouping them into a user''s datamodel.
(Not normalized, but with the definitions a user understands.)
That rude model is used by me to make a normalized datamodel and in the process I verify (using the user model) the definitions to get a sound normalized datamodel.
Finally I start with creating forms around the found "basic" tables and use the Object/Action principle. (I show a main form with all occurrences so the user can filter the set (s)he needs) and add the Action buttons like [Add], [Update], [Delete], [Print], etc.
That will cover some 60/70% of the needs and give me a model to tune with the user and add the additional requirements. (Kind of prototyping)
Finally I finish the database by adding the last specific functions and creating a userguide.
The design is more or less continous during the whole process and will take some 25 %, the database design and form/reports/etc. will take some 50% and the last 25% is for testing and documentation (userguide).
Nic;o)
最后，我开始围绕找到的基本创建表单。表并使用Object / Action原则。 （我显示所有出现的主窗体，以便用户可以过滤他需要的设置）并添加动作按钮，如[添加]，[更新]，[删除]，[打印]等。
这将涵盖约60/70％的需求，并给我一个模型来调整用户并添加额外的要求。 （原型的种类）
Finally I start with creating forms around the found "basic" tables and use the Object/Action principle. (I show a main form with all occurrences so the user can filter the set (s)he needs) and add the Action buttons like [Add], [Update], [Delete], [Print], etc.
That will cover some 60/70% of the needs and give me a model to tune with the user and add the additional requirements. (Kind of prototyping)
有趣的方法。我会发现这个耗费时间，特别是对于多用户系统，他们经常要求他们不需要的东西，每个人都想要自己的小特殊功能。我发现需求收集并与用户和管理层一起设计他们在设计阶段实际需要的东西可以节省大量的时间。
Interesting approach. I would find this time consuming as particularly with multi user systems they often ask for things they don''t really need and everybody wants their own little special features. I find that requirements gathering and working out with users and management what they actually need during design phase saves an awful lot of time.
这篇关于你应该花多少时间在设计上？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
