结论，月球上的微光薄雾根本不可能是地球人一直猜测的月球大气层，而是一些漂浮在月球地表上的尘埃。在书中，有一段主人公关于这种科学预言的令人印象深刻的谈话。一位宇航员首先问到：“月球表面的物质是最肮脏的导电物质，月表的灰尘不停地扬起又落下，因为这种运动摩擦，所以它们通常都是带电的。当灰尘带上电荷，将会发生什么事情呢？”另一位宇航员回答：“灰尘颗粒们会相互排斥。”提问者继续问到：“如果一个周长绵延数百公里、边缘高达几公里的环形山都带上电荷，那落在这座山上的灰尘将会发生怎样的奇迹呢？”科幻小说作者凭借自己超凡的想像力描绘出的答案是：那些灰尘将会在静电作用下，像一座巨型的喷泉一样，在阳光下升腾不止。
哈尔·克莱门特自己都不知道，他描述出来的幻想情节，与后来的月球登陆车拍摄的照片以及登月宇航员亲眼见过的情景再吻合不过了。在宇航员乘坐阿波罗11号登月之前，人类就向月球派出过一些勘测飞船。勘测飞船软着陆在月球表面后，立即向地球传回了大量让当时的人们迷惑不解的照片。照片中显示，在离月球地面不远的空中，总有一些有如黎明到来时的微弱光芒在闪耀，非常清晰，并且这种状况会一直持续到黑夜来临。此外，由于月球上没有大气对阳光的散射作用，它的地平线应该如刀片一样的平直锐利才对，但是月球地平线并没有将天空与月表泾渭分明地分割开来，而是有一个逐渐模糊的过渡带。
最让人们感到惊讶的，是于1972年乘坐阿波罗17号飞船环月飞行的宇航员们所见到的奇观。在月球上的日出与日落的前后10秒钟之内，宇航员们反复看到了被他们叫作“丝带”、“白帘”或者“晨曦”的光幕，他们把这些奇怪的光影通过素描速写下来了。同样的光影，也被乘坐过阿波罗8号、10号和15号的宇航员们看见过。
“喷泉”，电荷在作怪
在地球上，我们也能看见与这种光芒相似的夕辉或者晨曦。日出和日落时分，当太阳的光芒被山峦阻挡，常常在天空中留下对比强烈的光柱和阴影，这是由于阳光照射到空气中的尘埃时，气溶胶态的尘埃对光发生散射，我们就看见了光柱。人们猜测，也许月球上的微光也是那样产生的吧。在上世纪70年代，当宇航员们展示这个月球上的怪事时，许多行星天文学家就是这样解释的，甚至将这种推论写成了科学论文。
但是，既然月球上没有大气，那些灰尘如何能够长久地漂浮在月球表面呢？即使有陨星冲击月表造成灰尘颗粒暂时飞溅上升，那些灰尘为什么不很快地回落到月球表面上呢？
为了解释这个现象，美国宇航局戈达德航空飞行器中心的物理学家们建立了月尘运动的“动态喷泉模型”。这个模型解释到：实际上，月球上空存在着一种由极为纤细的不停运动的带电微粒组成的“大气”。这里借用“喷泉”这个词语，不是因为那些微粒是水分子，而是希望用喷泉这种直观的比较对象来说明那些微粒“大气”是如何在运动的。月尘带电微粒从月球表面上连续不断地升起来，又连续不断地回落下来，前赴后继，最后的结果形成了尘埃的喷泉，看起来就像是月球近地表面一层静止的“尘埃大气”，只不过是这个“大气层”完全由连续运动的带电尘埃颗粒组成。
这种喷泉模型其实并不神秘，在我们身边，就经常发生这样的事例。将充气的气球放在头发上摩擦数下，然后离开头顶几厘米，你的头发马上就会朝向气球树立起来。这是因为在摩擦气球的时候，电子会从头发上跑到气球上去，从而使头发带上正电而气球带负电。正负电荷相吸引，就会导致本来下垂的头发随着气球直立起来了。当将带电的气球完全拿开后，你的每根头发会彼此分开，整个头部的头发像一把张开的伞一样都扩张开来，持续一段时间后才慢慢回到原来的自然状态。这是因为当带电的气球移开后，每根相邻的带有正电荷的头发会因为同性相斥而彼此远离，部分头发就会成悬着的状态了。这与带电的月尘悬浮空中的道理完全相同。
月球上布满带电的“喷泉”
不过现实中的月尘颗粒并没有科幻小说中所说的那样因相互摩擦而生电，月尘是从太阳那里得到静电的：一方面通过阳光照射捕获光能产生静电，另一方面通过来自太阳本身带电的粒子获得电子，如太阳风。
在月球的日照面，由于太阳紫外线和X射线等各种高能射线的轰击，月球表面尘埃物质的原子与分子中的电子发生跃迁，直至电离。月尘微粒所带的正电荷逐渐积累，电荷越来越强，直到使尘埃微粒相互排斥开来，甚至离开月球表面，上升到数米甚至数千米的空中悬浮起来。由于月尘非常微小，一般直径不到一微米，所以在整个月球日照地区所形成的壮观的带电灰尘带，并闪闪发光，让人误以为是“月球大气”。这种奇观即使在宇航员登陆月球后，也能被清楚地看见。
那么，在月球的背日面又会发生怎样的故事呢？那里实际上也会发生月尘喷泉，不过那些悬浮到空中的月尘所带的电荷不是正电荷，而是负电荷。这些负电荷来自于太阳风中所携带的电子，再加上那些在日照面被太阳风激发出来的负电荷，会一起随着太阳风流向月球的背日面。实际上，根据喷泉模型的试验证明，背日面所带的电量比日照面还要高得多，在那里的月尘微粒会飞扬得更快更高，也就是说，背日面的月尘喷泉实际上喷涌得更猛烈，更壮观，只不过没有阳光的照射而无法被人们看见或者拍照了。
好问的读者马上就会发现一个问题：在月球的白昼与黑暗的分界线上，又会发生怎样的事情呢？而我们知道，月球也如地球一样，日出与日落造成的昼夜分界线总在周期性地移动，这种运动又会产生什么后果呢？物理学家们根据喷泉模型推测：在分界线区域，将会形成一种非常强大的地平线电场，电场会导致月尘像流体一样在地平线上空横向流动，最终边界区域的灰尘被电场全部吸光。当然，月尘微粒太小了，以致宇航员无法用肉眼看见那些在地平线附近急速奔流的尘埃巨浪。不过，当你身处地平线附近的黑夜区欣赏月球上的日出时，你会在地平线上看到一幕极为怪诞的晨曦光芒，它们很薄，像是一匹巨大的白布帘在地平线的上空舞动不已。
戈达德航空飞行器中心的研究人员正在进一步探求与月尘喷泉相关的一系列迷人的问题。例如，对那些极深的月坑，因为终年照射不到阳光，经过数以亿年计的时间，会不会累积出极强的负电场呢？了解它们是极重要的，因为那些终年背阴的火山深坑里面，是月球水资源的最大储存地，那里是人类月球殖民基地的最佳选址。如果那里充满了密密麻麻带电的尘埃，人类将如何应对呢？
1、喷泉模型的优点喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 2、喷泉模型的缺点由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
关于无缝的特性：软件开发通常来说会划分明显的阶段，比如使用瀑布模型时，只有在设计完成之后才能实现，但喷泉模型却可以同步进行这些步骤，这更符合实际开发的状况。
关于迭代的特性：软件开发的每个步骤通常都需要“返工”，喷泉模型很好的支持了这一点，使得迭代开发
喷泉模型（fountain model）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
对软件工程的一点看法--希望能够抛砖引玉
在这里看到很多网友的高论，很有启发。而且目前市面上也涌现出一批面向不同方面的软件过程的书籍，可是在这里，我一直没找到真正对实践有指导意义的，可操作的应用方法，所以现在这儿抛块砖，望各位高手指正。
我个人的理解，软件工程就是按照工程学的管理方式，有组织、有计划的，在一定的质量基础、时间限度和成本范围内，实现功能明确的软件系统。而且，软件工程在企业范围内运行，一定需要企业资源的支持，要与企业的经营、决策、管理体系联系在一起，才能够被踏踏实实的落实下来。
软件业作为一个服务业，要想得到发展，首先必须形成一个对软件服务有迫切需要的市场。其次，这个市场中的消费者必须具备足够的购买力。软件的消费群体简单一点，可以分为个体消费和企业消费。中国的企业群体，数量庞大，但是质量不高。上规模的企业极少，因此，中国的企业对大型软件的消费肯定是有限的，软件的个人消费，至少目前在中国，还是不成气候。因此，国内目前能够形成比较大规模的独立市场的，肯定是小规模的软件系统。
此外，质量的好与坏也不能绝对而论。比如说，你花500元，买双皮鞋，只穿了一个月就坏了，肯定是劣质产品。可是如果你只花了5元买这双鞋，还是穿了一个月就坏了，他就是个优质产品了。软件也是一样。
还有一个，就是软件生命周期问题。在国外，很多中、大型企业里，软件系统已经作为企业的命脉在运行，这些企业当然需要长期、稳定的软件服务、开发体系作为保障，因此相对来说，对于软件的功能需求就比较明确，而国内的中小企业在运营方面本来就把灵活多变作为生存武器，当然不可能有比较长期的经营计划，更不可能运用软件系统进行全面企业管理。这就导致对软件系统需求的短期行为，因此，他们更加希望一次性购买功能有限的软件系统，而不是长期连续的软件服务。
如果上面的分析有代表性的话，那就是说我们现在必须对开发这类软件形成一套非常有效的工程方法：
1。规模小。
2。成本低
3。质量要求不高。
4。售后服务有限。
5。生命期短。
我想，对于这类系统，RUP未必是一套好的方法。另外，我还想谈谈对软件人员素质的看法。
从我个人的经历来说，我觉得我们对于软件工程师的培养方法有问题。理论上说，软件只要设计了一个好的结构，解决了所有的技术难点，剩下的代码高中生就能做。实际上我们的很多名牌大学的计算机专业毕业生都不能很好的Coding。尤其是现在有了VB、PB、JAVA之后，大家似乎认为计算机的体系结构都不用关心了。我曾经经手的几个软件项目中，很多工程师对于用C语言开发Win32多线程、事件驱动、死锁、内存分配等问题根本束手无策。我不相信这些问题可以靠很好的文档解决。实际上，能够用OO的工具工作，根本不代表能够进行OO的系统分析与设计。
话又说回来，在中国，有10年以上软件开发背景的人，又有几个？而且他们在过去10年里的经验，更多的是小项目的Coding，而不是大项目的管理与系统分析。而一个好的系统分析师，需要的是实践、实践、再实践。假如说我们的商业环境中根本没有大型的软件项目，怎么可能有优异的系统分析师呢?
所以，我想，目前我们的问题，是工程师的技术水平、知识面与管理意识、管理方法同样重要，在这样的前提下，我们是不是要探索一下真正适合我们的软件工程方法呢？
