维克苗综合站

缺陷跟踪系统
    BUGZERO? 是一个多功能，基于网络 (web-based) 并在浏览器 （browser) 下运行的 Bug缺陷管理和跟踪系统，可用来记录，跟踪，并归类处理软件开发过程出现的 Bug 和硬件系统中存在的缺陷（defect）。 BUGZERO 也是一个完整的服务管理软件，包括集成服务台热线流程管理（Help Desk），可用来记录各种日常事务，变更请求，和问题报告，及追踪和处理各种客户讯问，反馈，和意见。
BUGZERO 提供了一个可靠的中央数据库使公司内部团队成员以及外部客户能在任何地点任何时间进行协调和信息交流，并且使任何记录都有据可查。它使你省时省力。BUGZERO 不但使用方便，而且功能齐全，变通性好，能够灵活设置各种实际工作流程，满足你特定的业务和产品环境下的需求。这种灵活、易用的缺陷跟踪流程不仅增强了项目开发的质量，同时也提高了整个机构的生产效率。
BUGZERO 是一发展成熟的软件产品，已在国际市场上流行。它界面的中文汉化，将会更好地为广大的中国客户服务。
BUGZERO 特点  
- 采用标准技术，基于网络，多功能，快速，可靠，好用性好
- 无需在用户终端机器上装任何附加软件，可从网络上任何地方通过HTTP 或SMTP 联接
- 支持网页界面和电子邮件界面，内部网和外部网的用户均可使用
- 使用 Java? 和 J2EE? 技术，服务器可在任何操作系统下安装
- 支持各种数据库系统，基于 SQL92 标准，使用开放型数据库设计，可升级
- 可设置性和多用途,不仅可用做 Bug 跟踪系统，而且可用做集成服务台热线流程管理
- 支持各种自定域数据类型，表格栏目可根据需要添加和删减
- 页面可做个性化调整，如添加公司标志等
- 可同时支持多个项目，设置访问权限，自我注册
- 可设置基于表格栏目域的多层次权限
- 自定义工作流程（对每个项目）
- 自动或手动分配任务负责人
- 可一次附加多个任何类型的文件
- 支持直接屏幕抓图（Screen capture）
- 具有自动自定义电子邮件通知功能
- 可通过电子邮件和文档版本管理软件 (CVS, Perforce) 集成
- 图表报告，高级搜索，自定义常用搜索
- 全面且易读的记录和修改历史
- 快速排序和导出（export)，支持 Unicode 亚洲语系
- [...]

Don’t try to run with the hare and hunt with the hounds!
别想两边讨好！

—————————————————————————————————
　　固定搭配run with the hare and hunt with the hounds或者hold with the hare and run with the hounds字面意思是“跟着兔子跑，跟着狗打猎”，相当于汉语中的“两面讨好”。注意：这个表达中，hare使用的单数，hound使用的复数，这是一个固定的表达，我也不知道为什么。^_^
　　例句：I know how to handle two-faced people and can even tell at the first glance who are in the habit of running with the [...]

在SourceSafe安装目录下找SSINT.EXE文件运行一下即可。
如：D:\Program Files\Microsoft Visual Studio\Common\VSS\win32\SSINT.EXE
注：如果一开始安装过SourceSafe 6.0 再安装SourceSafe 2005 ，Visual Basic 就会和SourceSafe 6.0关系起来，只要把SSINT.EXE复制到SourceSafe 2005 的安装目录下再运行一次即可(因为我在SourceSafe 2005 的目录下没找到SSINT.EXE)

——————————————————————
公告栏
———————————
留言板
———————————
看广告玩游戏送QQ币

最让人感兴趣的也许就是前面介绍的利用扩展存储过程xp_cmdshell来运行操作系统的控制台命令。这种方法也非常的简单，只需使用下面的SQL语句：
EXEC master.dbo.xp_cmdshell ‘dir c:\’
但是越来越多的数据库管理员已经意识到这个扩展存储过程的潜在危险，他们可能会将该存储过程的动态链接库xplog70.dll文件删除或改了名，这时侯许多人也许会放弃，因为我们无法运行任何的cmd命令，很难查看对方计算机的文件、目录、开启的服务，也无法添加NT用户。
对此作过一番研究，后来我发现即使xp_cmdshell不可用了，还是有可能在服务器上运行CMD并得到回显结果的，这里要用到SQL服务器另外的几个系统存储过程：sp_OACreate，sp_OAGetProperty和sp_OAMethod。前提是服务器上的Wscript.shell和Scripting.FileSystemObject可用。
sp_OACreate
在 Microsoft® SQL Server™ 实例上创建 OLE 对象实例。
语法
sp_OACreate progid, | clsid,
      objecttoken OUTPUT
      [ , context ]
sp_OAGetProperty
获取 OLE 对象的属性值。
语法
sp_OAGetProperty objecttoken,
      propertyname
      [, propertyvalue OUTPUT]
      [, index...]
sp_OAMethod
调用 OLE 对象的方法。
语法
sp_OAMethod objecttoken,
      methodname
      [, [...]

新版本已经写好，但还有一些BUG，这次是用Visual Basic 6.0写的，只有系统中安装了IE7才可以使用，这次的软件也不用安装，文件非常小压缩后只有64K，而且还可以自定义刷新时间。这次不但支持hi.baidu，还支持blog.sina 和　blog.sohu.软件名暂定BlogKing(经过一段时间的测试，百度和新浪比较稳定，sohu 不稳定)

旧版本不再提供下载,请下载百度空间留言助手

________________
注：软件只是供大家学习,欢迎报告BUG

——————————

1. 你们的项目组使用源代码管理工具了么？
MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2. 你们的项目组使用缺陷管理系统了么？
MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。
3. 你们的测试组还在用Word写测试用例么？
MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 你们的项目组有没有建立一个门户网站？
MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你们的项目组用了你能买到最好的工具么？
MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。
6. 你们的程序员工作在安静的环境里么？
MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
7. 你们的员工每个人都有一部电话么？
MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么？
MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。
9. 你遇到过有人说“我以为…”么？
MVM：要消灭“我以为”。Never assume anything。
10. 你们的项目组中所有的人都坐在一起么？
MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况？
MVM：应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
12. 你们的工作量是先由每个人自己估算的么？
MVM：应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
13. 你们的开发人员从项目一开始就加班么？
MVM：不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？
MVM：不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
15. 值得再多花一些时间，从95%做到100%好
MVM：值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
16. 登记新缺陷时，是否写清了重现步骤？
MVM：要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。
17. 写新代码前会把已知缺陷解决么？
MVM：要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
18. 你们对缺陷的轻重缓急有事先的约定么？
MVM：必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev [...]

本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本…  
  
   　　本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。因此，需求分析过程不同于建立一个全新的系统，大体上可分为三个阶段：（）实施逆向工程获得对系统的初步了解；（2）在第1步的基础上写出基本需求，交由客户评审补充；（3）在第2步的基础上开发原型，利用原型与客户交流，最终获得基线需求。针对上述三个阶段，本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自己的初步体会。
　　我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发工作，该大型集团的业务主要涉及到IT类产品的进销存。本人在项目中负责系统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1～2分钟左右的响应时间，让客户无法忍受。（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采用人工录入方式补充进行。在这种情况下，该集团的总经理决定参考原有系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。注；原系统采用PB6.5开发，数据库采用SYBASE，服务器采用Windows2000Server，客户端采用Windows 98，程序架构采用的是传统的C/S结构。
　　鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题，我们决定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化，因此，我们把需求分析的过程分为三步：（）分析原有系统的结构，主要是数据库结构和程序结构，（2）在获得第（1）步结果的基础上写出基本需求，交由客户评审补充，（3）在第（2）步的基础上开发原型，利用此原型与客户交流，从而获得最终可用的需求结果。下面按上述三步分别加以论述。
　　第一步是实施逆向工程，获取原有系统的基本需求
　　由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发中也积累了不少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。在这一阶段，我们采用的主要工具是PB自带的Power Designer和PB Documents；前者主要用来分析数据库结构，后者主要用来分析程序结构，便于开发人员与高级用户理解程序。采用这两个工具的原因是：原系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较完整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，于是我们只能依靠工具辅助来进行。在使用Power Designer分析数据库，并且用PB Documents分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文档。这里指出，使用Power Designer的一个不足之处是：如果一个表中的字段过多，而且又同时依赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅读及打印。
　　第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和补充
　　通过第一步的逆向工程，我们获得了系统的基本需求。为了充分记录需求的变化及需求之间的依赖关系，我们决定选用Rational公司的Requisite PRO作为我们的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常强大，包括Requisite Pro、Clear Quest等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间的依赖关系等等。但是，我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就是记录需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。之所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充整理后的需求作为正式需求记录入Requisite Pro所维护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必须优先考虑的，哪些是难度较大的等等。  
　　在这个过程中，我们遇到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系；另外是由于首次采用Requisite Pro进行需求管理，在类型划分，属性值的确定上，部分开发人员没有经验，造成了不少反复，对于前者，我们的方法是想办法增加一些示意图，将大的流程分解为小流程，再与客户反复交流与沟通，最终达到双方理解一致的目的。对第二个问题，则参考了一些例子，再结合实际中属性的使用情况，给予取舍或者选择，经过这一阶段的工作，我们建立了基本的需求库，定出了基本需求规格说明。
　　第三步则是在第二步的基础上建立起原型，利用原型与客户进行更深入的交流，通过交流修改相应的需求
　　在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的。我们用PB开发了一个原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，客户发现了许多我们与他们的理解相互不协调的地方，我们在修改需求的同时，也在Requisite Pro需求数据库中记录下修改的历史。事实证明，这种记录历史的作用是很有效的，如曾经有客户在两个不同的时间对同一需求提了相反的需求，我们根据历史记录很快证实了该客户的提法有错误，在事实面前无需再作争论，同时利用Requisite Pro，我们还发现了一些需求相互之间有矛盾。经过这一阶段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行详细设计的基线需求。
　　在这个项目中，我们利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具，这些工具的使用，使我们提高了工作效率，起到了一定的辅助作用。但是，就需求分析工具方面而言。我们觉得国内应用得还是太少了，这一方面是因为对需求分析不够重视，另一方面是因为管理水平还达不到相应的层次。Rational公司的一整套需求分析工具，其功能是非常强大的，国外已在普遍地使用，在国内也逐渐开始普及，特别是那些通过CMM二级以上评审的单位，都必须使用工具对需求进行管理。在本项目中，我们仅仅利用了Requisite Pro功能的一些小方面，已经体会到该工具对于项目管理的诸多好处。如果一个有实力的公司能够全面实施RUP，那么需求管理这个老大难的问题会变得不再那么棘手了，项目的质量也会得到相应的提高。目前国内由于CMM热潮的兴起，已经逐渐重视需求分析，也逐渐使用需求分析工具，这是非常可喜的，当然，更希望在不久的将来，能用上国产的需求分析工具，那时我们的软件产业也许会真正地腾飞了。
　　评注；采用逆向工具进行再工程的应用很多，本文给出了一个实际的例子。写作有条理，也很实际。合理地界定了需求分析的现实水平。所采用的需求分析的方法与工具相对较合理科学。能在对项目讨论的同时抒发议论、使用体会、爱国心和事业心。深度还可以提高，例子宜更加丰富一些。

文章来源: 项目管理者联盟

使用VisualBasic（以下简称VB, 版本为6.0SP4）可以快速设计出标准风格的Windows软件，但是要创建真正易用的图形界面，还有许多工作要做。
一、窗体设计
窗体设计的好坏往往影响到软件的整体形象，因此必须首先处理好窗体的设计问题。
1、 窗体的边框
　　窗体边框的默认风格为“Sizeable”(可变的)，但并不是所有窗体都可以使用可变边框。因为用户常常有意无意地改变窗体的大小（比如双击窗口的标题栏），如果窗体中包含大量的控件，极有可能遮住部份控件或由于窗体过大而使控件的相对位置发生变化，使用户产生疑惑。
　　解决该问题的一种方法是在form_Resize事件过程中动态改变控件的位置和大小，使之在窗体中保持相对位置，但缺点是当窗体过小时，很难保证控件的可视效果。当然可以用程序控制窗体的最小尺寸，但更简单的方法是将窗体边框设置成“Fixed Single”, 如果不想提供最大化或最小化功能，也可以将其设为“Fixed Dialog”。
2、窗体的初始位置
　　窗体的初始位置会直接影响用户的使用，特别在多窗口的环境中，如果新的窗口完全覆盖了先前的窗口，用户一定会以为原先的窗口丢失了。使用层叠方法排列窗口并在任务条上显示每个窗口的进程标题是个不错的选择。 模式窗体激活时会阻止用户操作其它窗体，因此必须在不需要同时使用任何其它窗体的情况下才使用模式窗体，并确保窗体是可移动的。
3、使用多文档窗口界面
　　在多窗口界面中，所有窗体都以桌面为依托，好象有多个应用程序在运行一样，窗口管理比较麻烦，采用MDI多文档界面会将窗口管理的复杂程度降到最低。
　　在多文档界面中，必须有且只有一个主文档窗体（MDI主窗体），它的窗体区域不能放置除菜单类组件以外的任何控件，但可以拥有多个子窗体（MDI子窗体），也就是说MDI子窗体不能独立存在，并且不能为模式窗体，它们只能在MDI主窗体的窗体区域内活动；子窗体最大化时其标题栏和菜单栏能和主窗体合并；最小化时子窗体并不会缩至任务条上，而是缩小至主窗体的左下角；关闭主窗体时，所有子窗体都能自动关闭。充分使用好MDI界面会使用户觉得窗口控制更加简单。
4、控件的安排
　　控件是窗体最主要的组成部份，其排列形式会对用户操作的直观性和易用性产生重要影响。控件的放置一般 裱 韵略 颍?按功能组织控件的位置。
　　将控件按功能分类放置于窗体的不同的区域，会让用户更容易找到所需的功能。如果将“字体”和“取消”按钮放在一起，而将“颜色”和“确定”按钮放在一起，用户一定会摸不着头脑。
　　在保证可视性良好的前提下，控件的尺寸应尽可能地“小”，这样可以尽量缩小窗体的尺寸。
　　不在过小的窗体中放置过多的控件。
　　在过小的窗体中放置过多的控件，会造成窗体元素的过分拥挤，使控件的标题和文本难以辨认。
　　如果可能，应在按钮控件中使用图标，这样既可以使画面更生动，又使用户更容易理解控件的作用。
　　使用控件的“ ToolsTip ”属性。
　　“ToolsTip”可以为控件加上浮动的提示条。当用户的鼠标指向该控件时，提示条会自动显示，让用户立即从文字中了解控件的功能，数秒钟后它还会自动消失，不会给用户带来视觉障碍。
二、菜单设计
　　菜单是界面设计中的重要组成部份，“简单、直观、一致、有效”是菜单设计的原则。
　　下面的建议可能对创建满足用户期望的菜单有所帮助。
　　按照逻辑功能将菜单项分组，并且在下拉菜单中用分隔线将功能更相关的项目分组排列。
　　在同一菜单中避免使用多个相同功能的菜单项，否则会使用户产生疑惑。 避免使用没有下拉项的菜单项，因为孤立的菜单项和按钮没什么区别。点击这类菜单项并直接产生某个动作，通常会给用户产生过于 “突然”的感觉。
　　为了使用户使用更方便，可以在相关的窗体或控件区域内设置弹出式菜单，特别推荐用鼠标右键弹出菜单。同时这些弹出式菜单可以在主菜单中保留副本。 如果单击某个下拉菜单项会弹出对话框的话，最好在菜单标题的末尾添加“…”（省略号），这是Windows的约定。这样会使菜单更接近标准的Windows菜单，给熟悉Windows操作的用户带来方便。
三、照顾用户的感觉
　　用户的感觉是检验软件成功与否的试金石，这种感觉包括对软件的外观、易用性和速度等许多方面。
通常用户单击图标、控件或者菜单项时总希望看见一些事情发生。如果在单击后屏幕上没有发生变化，用户可能产生困惑，或者以为没有按对鼠标，或者干脆怀疑程序是否已经“死”了，但实际上程序可能正在处理一些需要较长时间才能完成的事情。结果不是为了确认鼠标是否按下而多次运行了同一个程序（这会使情况更糟），就是程序被强行关闭。这是我们不愿看到的。
　　解决的方法很简单，只要在开始处理前显示一个等待画面，如显示一条诸如“正在处理数据，请您稍候…”之类的信息，如果能配合显示动画图标和进度条，则效果更佳，它给用户的感觉就会变成：程序正在“拼命”地工作，而且很快就会完成了。
　　如果整个程序的启动时间过长，也会造成同样的情况。可以用类似的方法来解决：显示一个“闪现”画面（Flash Screen），在显示过程中完成启动处理，然后关闭“闪现”画面，进入主程序（类似Word的启动画面）。需要说明的是，要显示“闪现”画面，最好使用Sub_Main()作为程序的入口。
　　一些带有许多窗体的程序在运行时不断地装载或卸载窗体，用户感觉很“慢”，一个行之有效的方法就是在程序启动阶段将常用的窗体用Load语句预先装入内存（不显示），需要的时候只要用窗体的Show方法就能立即显示出来。虽然这有可能增加程序启动的时间和对内存的要求，但程序运行时的性能表现要快得多。
另外，用户对于不受他们控制的程序操作大多比较反感，因此让用户有机会取消操作将会更体贴用户。
　　一般在执行某个关键操作前，可以显示一个对话框，它至少包括两个按钮：“确定”和“取消”，这样可以给用户“反悔”的机会；在执行一些需要长时间才能完成的动作（比如数据复制）的过程中，在不影响数据安全性的前提下，可以提供一个“取消”按钮，让不耐烦的用户有机会终止操作。在设计这种功能时要熟练使用DoEvents语句。
　　以上只是本人在使用VB编程过程中的一些经验和感受，希望能为广大的VB程序员起到“抛砖引玉”的作用。

NSIS (Nullsoft Scriptable Install System)是一个Open Source的Windows系统下安装程序制作程序。它提供了安装、卸载、系统设置、文件解压缩等功能。这如其名字所指出的那样，NSIS是通过它的脚本语言来描述安装程序的行为和逻辑的。NSIS的脚本语言和通常的编程语言有类似的结构和语法，但它是为安装程序这类应用所设计的。NSIS脚本通常以 nsi为扩展名，支持include功能，头文件扩展名为nsh。
NSIS的主要特点是：
开销小，一个完整功能的安装程序仅需要34k的额外开销。
支持大多数Windows平台，包括：Windows 9.x，Windows NT, Windows 2000, Windows XP, Windows 2003
支持三大压缩算法: Zlig, BZips, LZMA
支持脚本
支持多语言
支持安装界面定制
提供可扩展的插件接口
支持网络安装、补丁
支持无人值守的安装模式
此外，NSIS的license允许任何用途免费使用。
开发一个NSIS的安装程序通常有以下几步：
确定安装的功能和界面元素
编写NSIS脚本
使用NSIS提供的makensis或者makensisw程序，将步骤2编写的脚本编译成可执行的安装程序
调试安装程序，如果有问题退到第二步重复
随着NSIS的流行，有一些第三方的NSIS脚本开发环境出现了，如HM NIS Edit，Venis IX前者是完全开源的，后者仅对个人和非商业用途免费。在这些集成开发环境下，步骤2，3可以方便的组合在一起。
NSIS脚本的结构
NSIS脚本(下称nsi脚本)主要包含安装程序属性、页面、区段、函数。
属性用来定义安装程序的行为和界面风格，这些属性大部分是编译时刻属性，即不能在运行时刻改变。
页面是指安装程序的向导页面，示例：
Page license
Page components
Page directory
Page instfiles
UninstPage uninstConfirm
UninstPage instfiles
区段是对应某种安装/卸载选项的处理逻辑，该段代码仅当用户选择相应的选项才被执行。卸载程序的区段名用”un.”作为前缀，示例如下：
Section “Installer Section”
SectionEnd
Section “un.Uninstaller Section”
SectionEnd
在区段中可以使用很多指令用来完成诸如解压缩文件、读写注册表、创建目录、创建快捷方式等任务，但最常用的指令是SetOutPath和File，前者用于指定目的位置，后者用于指定文件。示例：
Section “My Program”
SetOutPath $INSTDIR
File “My Program.exe”
File “Readme.txt”
SectionEnd
区段名的修饰符/o表示该区段默认不选上，-表示隐藏区段(匿名区段也是隐藏区段)，！表示需要粗体显示的区段。
SectionIn表示该区段和安装类型之间的关系：
SectionIn insttype_index [insttype_index] … [RO]
RO修饰符表示不可修改。
子区段用于包含多个区段
SubSection [...]

1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY