再问关于软件工程(50分)

在一个软件项目拿到手后,做计划分析时
的最正规的步骤,请科班出身(我是学通信的)的给咱介绍一下

那你不如找本软件工程的书看一看。但是否按书上的步骤做，要根据你的项目大小取
舍。

书上讲的好像和实际差的很多,我想找一份比较贴近实际的答案.

书上写的是大工程啊...
一般大公司都有自己的一套,自己写写的话,只要数据库分析搞定就可以了

大家都希望规范,但真做到规范不太容易.尤其是在现在的中国,那家软件公司做好了?即便是大工程又怎么样?是不是要象建筑行业一样派监理?用户如果没能力,谁知
道你们的做法符合规范?而且在规范上的人力物力投入相当大.想想吧,还要不要规范.

我有一套规范，你要不要？

真的要规范吗？哪是很乏味的东西！（但是很有效）

我来说一把,对于一个大的项目来说,分析设计、编码、测试所占的比重为40：20：40
之所以编码的比重很小，是因为有代码自动生成工具，对于手工作业，编码的比重比较大一些，但比重不超过分析设计，在现有的条件下，测试所占的比例也可小一点。
总而言之，分析设计是最重要的阶段，它直接影响到以后的过程，将其比例上升为50
不为过。分析设计包括需求分析、概要设计和详细设计。

要是东西不大
又不想以后让灭人俩维护
还是把让软件工程扔一边吧
不过作数据库画个E_R图是挺必要的

哪里有 ER-WIN 我的不知道到哪里去了:-(
我一直想写个中文的 ER-WIN，E文不舒服，可是，呵呵，只是想而已。
数据库规范还是很重要的。

要设计好程序你必须
1.收集“素材”,分析它，选择一定的数据结构。
2.画流程框图！(这是非计算机专业的人士最不愿干的事！)
3.根据流程框图写出算法框图。
4.选择语言(根据你收集的“素材”、软件的要求等)
5.编写程序
6.调试程序
7.有可能的话写一分设计任务书、使用手册等

to 茶叶蛋:
当然要了!
谁有ER-WIN?

我倒是有ERWIN,大约25M,cracked.大概用email传不大合适，不过我是从“爱国软件热炕头”上下载的，不过我忘了地址，在网上问问吧
顺便说一句，ERWIN确实比SDESIGN好用许多。

刚查到地址http://chat.cn2000.net/~wing/iso1/
down 去吧

微软公司的 Quill ‘96 计划书，可以参考
Quill ‘96 Development Plan
David Bangs - updated May 2, 1995
Introduction
Thisdo
cument serves as a “Schedule Companion”do
cument discussing development issues for three components: QuillDocument ‘96 and its accompanying OLE control will be used by Bob 2.0 applications, the Sundance 2.0 home DTP package, and the Blackbird online Viewer. QuillStories ‘96 and QuillStories ‘96J (Far East release) will be used by the Escher drawing component server, which will ship in Office ‘96 and Publisher ‘96.
The schedules are being developed using Excel macros provided by the Office group. These macros are capable of generating very readable reports, including summaries that indicate the rate of schedule slippage from week to week. Printed copies will not be distributed since the schedule will be available at a published location on the network.
QUILL96.XLS - Contains all tasks relating to the creation of the QuillStories ‘96 and QuillDocument ‘96 components.
QUILL96J.XLS - Contains tasks relating the creation of the QuillStories ‘96J component, which will be completed by 3 developers after the non-FarEast QuillStories ‘96 component is complete.
During the development phase, the schedule will be updated weekly. Every Monday, programmers will revise a printout of their schedule and turn it into DavidB, who will maintain the central Excel schedule.
For more information about the Quill ‘96 project, contact Dean Hoshizaki (DeanHo), who can direct you to the appropriatedo
cuments, such as the QuillStories ‘96 and QuillDocument ‘96 specifications.
Target Dates and Milestone Summary
The driving client of QuillStories ‘96 is the Escher Drawing Server, which will ship with Office ‘96 and Publisher ‘96. Target milestone dates are determined largely by the Escher’s schedule, but also heavily influenced by the schedules of QuillDocument customers, such as the Blackbird 1.2 viewer and various MS-Bob 2.0 clients (LetterWriter, Sundance 2.0, and more).
The development of QuillStories will consist of two major milestones. MM1 will lead to “first deliverables” of QuillStories for integration into Escher. MM2 will lead to code complete of the QuillStories ‘96 component. The QuillDocument ‘96 component will also observe these milestones.
Three developers will be assigned to the QuillStories ‘96J Far East project shortly after the completion of QuillStories ‘96.
The following table indicates the major target dates we are shooting for.
Table 1: Target Dates in QuillStories schedule
5/1/95 “Final” Spec and Schedule complete. Milestone 1 begin
s (14 weeks)
7/31/95 Code Complete for MM1. Stabilization phase begin
s (4 weeks)
8/15/95 QuillStories “First Deliverables” due to Escher
8/28/95 Milestone 2 begin
s (14 weeks)
11/27/95 Milestone 2 ends (code complete).
1/20/96 Work begin
s on QuillStories ‘96J version. 3 developers will focus on finalizing Far East issues and compiling on the MIPS platform. (12 weeks)
2/15/96 Golden QuillDocument ‘96 and QuillStories ‘96 released to clients (Escher, Blackbird 1.2, MS-Bob 2.0, and possibly others).
4/15/96 QuillStories ‘96J is code complete.
6/15/96 Golden QuillStories ‘96J is delivered to Escher.
Milestone Scheduling Details
Each milestone consists of a 14 development weeks, followed by a four week stabilization phase. The final milestone is followed by an additional four week stabilization phase.
Each Development phase is divided as 47 days for scheduled items, 14 days for inter-milestone stabilization work, 6 days for sick, vacation and holidays, and 2.5 days for code review issues.
The following table shows how days in a milestone are allocated.
Table 2: Milestone Definition
Major Milestone Development Phase - 70 days 65 days are divided into three categories Schedule Items 47 days (67%)
Intra-Milestone Stabilization Time 14 days (20%) (stabilization phase is included in the milestone to encourage developers to fix new bugs immediately, so that the component is stable at all times). This comes out to one day a week, but developers should not use this time unless needed.
Sick time, vacation time, and holidays 6 days Each developer is alotted one sick day per milestone. There are two holidays during the first milestone, 3 holidays during the second milestone, and 1 holiday during the J version’s milestone. Developers take an average of 3 or 4 vacation days per milestone.
Inter-Milestone Code and Design Review 2.5 days (3.5%) 2.5 days per milestone are dedicated to code and design review. This number will be slightly higher for a couple of developers.

Major Milestone Buffer/Stabilization Phase - 20 days. The milestone stabilization and bugfix phase comes out to 22% of the total number of days in an 90 day milestone. Total stabilization and buffer time (including the 14 days during the milestone) comes to 38%. There are 34 total days of stabilization and buffer, compared to 47 days of scheduled development tasks. This stabilization phase actually ends when the Milestone is certified by Quill Testing.
Major Work Items
Currently, Quill provides just one deliverable, known as QuillDocument. This component provides complete Word Processing functionality to clients. Though it has been useful to clients such as Creative Writer, MacWorks 4.0, and MS-Bob 1.0, the limited flexibility of this component prevents its widespread adoption by customers who want a text solution but provide their owndo
cument solution. To serve such clients, the lower layers of QuillDocument will be spun off as a separate component, known as QuillStories.
It can be said that QuillDocument is already a client of QuillStories. QuillStories consists of modules and functions which are already implemented and called by higher level functions. The process of separating the two components will be gradual. At all times during the process, QuillDocument should remain an intimate client of QuillStories. All QuillStories code can continue to be tested through QuillDocument and its test applications. In addition, we hope to adapt the Office Lime test application to test QuillStories directly.
But code separation is just the begin
ning of what we aredo
ing this year. Here I include two diagrams (courtesy of DeanHo) that outline the work to bedo
ne on the QuillStories ‘96 and QuillDocument ‘96 projects. For more information, see the schedules and specs.
Figure 1: QuillStories work

Figure 2: QuillDocument work

Development Resources
The key members of the QuillStories ‘96 development team are DavidB (lead and code separation), SiddA (architecture and client interfaces), ChipR (view issues), OLevy (Japanese and MS-TOM), DavidHoe (Macintosh support and feature work), and KeithCu (RTF support).
This years QuillDocument specific work will bedo
ne by AndrewFi (OLE container and control issues), KeithCu (feature and interface work), “NewHire” (to join us by September 1st - lower priority MS-TOM interfaces and features.), “OleActive” - (to join us by October 1st - U.I. Active OLE container support for the Blackbird team).
The J version (Far East support and MIPS build) QuillStories milestone will be staffed by OLevy (Win IME and vertical typing), DavidHoe (Mac IME and general Mac issues), and “NewHire” (MIPS build and J font issues).
Developers marked as “Not involved” in the J version will be spending that time stabilizing the non-J release and planning for the later Quill releases.
Table 3: Developer Area Assignments
Developer Major Work - MM1 Major Work - MM2 Major Work - J version
DavidB Development Lead (16 hours per week) Code separation tasks (24 hours per week) Development Manager (16 hours per week) Code separation tasks and limitted feature work (24 hours per week) Not involved
OLevy Microsoft Object Model Support in QD/QS. “Rationalize” QuillDocument client interfaces for MS-Bob 2.0 SDK Start Far East Issues. Unicode and IME support, and Kinsoku line breaks. Upgrade IME support to level 2. Vertical typing
SiddA Code separation tasks and client interfaces. (Prioritized as “First Deliverables to Escher) Further code separation tasks and client interfaces. Not involved
DavidHoe Compatibility with 16 bit files. Macintosh build issues Macintosh build issues QuillStories feature work Mac Far East support
KeithCu (Starts bt 6/1) QuillDocument - Improvements in Frame feature. QuillStories - Improvements in bullets. Horizontal Rules. RTF investigations. QuillStories - Read and write RTF (Rich Text only - no graphics) to file or clipboard. QuillDocument - feature work. Not involved.
ChipR Display “View” issues. Display “View” issues Not involved.
AndrewFi OLE control support IPersistStorage support DateObject work Provide keyboard accelerator table. BOB 2.0 issues Move OLE control to Forms3 OLE container issues Not involved
NewHire (To start by 9/1) Not hired yet Additional MS-TOM support and QuillDocument feature work. MIPS build and Far East font issues
OleActive (to start by 10/1) Not hired yet Inside-Out, UI active OLE container support Not involved.
Testing and PM Resources
DeanHo is serving as Quill’s program manager and test lead. Three testers will report to Dean.
SeanO currently maintains our test applications, and is focusing on QuillDocument issues.
We are interviewing for an additional test coder who can maintain QuillStories test applications for Win 32 Intel, Win 32 Mips, and Macintosh PowerPC platforms. He will be focusing primarily on the Escher client this year.
Michael Johnson, a campus hire from the University of Washington, will join the team in July.
Testing is responsible for creation of test applications, testing QuillStories and QuillDocument at the component level, and testing Quill’s components as exposed in client applications.
Testing has also agreed to providedo
cumentation for existing QuillDocument client API’s, as part of the process of validating these API’s.
Finally, Testing is responsible for validating weekly releases against multiple clients, which include Blackbird, Escher, multiple MS-Bob 2.0 applications, and eventually many more.
The Scheduling Process
The “Final” schedule is to be published around 5/1/95. At this time, most tasks should be divided into items ranging from 4 to 24 hours in length. Items shorter than 4 hours should be combined into one item if possible. Items longer than 24 hours should be subdivided into smaller items. This schedule will continue to evolve throughout the development process.
The schedule itself is being developed using Excel macros provided by the Office group. These macros are capable of generating very readable reports, including summaries that indicate the rate of schedule slippage from week to week. Printed copies will not be distributed since the schedule will be available at a published location on the network.
During the development phase, the schedule will be updated weekly. Every Monday, programmers will revise a printout of their schedule and turn it into DavidB, who will maintain the central Excel schedule.
Zero Defects
Quill development will follow “Zero Defect” development practices. The goal is for QuillStories and its QuillDocument client to be stable at all times. Things that work should work. Things that are in progress should be clearly in progress, rather than just subtly buggy.
The ZD policy is made up of the following parts
Developers should step through new lines of code in the debugger, exercising all code paths they have written, before checking in the code.
Developers should discuss the fix for each bug on Raid with another developer, prior to checking in the fix for the bug. This policy is based on the belief that the bug was created in the first place because of a tricky situation. Bug fixes are therefore more risky than other code changes.
During the development phase, no developer should accumulate more than 10 “new” bugs. A new bug is one that did not exist prior to the current milestone, and is reported against functionality that is thought to be complete. Developers with more than 10 new bugs should stop development tasks and fix them right away. Intra-Milestone stabilization time is provided to make this policy feasible.
Testing should provide an automated breadth test which should be run by each developer prior to checking in code. (After the OLE control is developed, we should be able to run the existing breadth test written in VB).
Work on the second milestone should not begin
until the first milestone is accepted by Quill testing.

已发出，1.06M，请查收。

其实我也为这事闹心！对每个项目来说，仅有通用的方法，但不是最好的

http://www.wellcity.com/Book/1.html

谢谢晓茶.
cj,唧唧歪歪:我在教育网,你提供的那个地方我去不了.

推荐两个软件系统分析设计CASE工具:
Rose 不直接支持Delphi,需要+Rose Delphi Link
and
WithClass99 直接支持Delphi
以在下愚见,对它们做了简单比较,不对之处,请高手指点.
Rose
在针对商用系统[C/S,B/S]开发时,开发思路显得非常清楚,可以从文档编制一直做到程序框架生成.
由此可知,Rose对我们编写分析文档用处不小.
需要学习或培训,操作复杂(我搞了两天,才算入门)
支持团队分析开发
文档编制规范
程序设计分析方面的支持弱
系统分析师必备!
WithClass99
完全针对OO(Object-Oriented)的CASE Tool.
在设计分析具体程序时,我感觉WithClass99非常棒,从OO程序框架到具体实现可以完全用WithClass99实现!
不需要学习或培训,使用简单(太简单,我down下来,装上就会用了[应该说是入门]!)
不支持团队分析开发
文档编制不好.
程序设计分析方面的支持强
程序员规范设计必备!
我是用Rose做原型设计,生成程序框架后,交给程序员转用WithClass99作程序设计!