- 博客(1133)
- 收藏
- 关注
RSS订阅原创 软件服务始终都要记住用户的选择
在设计软件界面时，我们的设计师经常会画新功能的UI设计图，来征求大家的意见。我注意到大部分设计都假设用户是头一次使用产品，所以没有任何积累的文件、照片、处理过的图像、曾经做过的选择等数据。你的产品是下面的哪一种:a.软件用得越多，一样难用b.软件用得越多，越发难用c.软件用得越多，越来越好用这本书的大部分文字都发表在博客上，我在写博客的时候，就被一个a类型的用户体验折磨了。1.用户上了银行的门户网站，把语言改成English，开始注册，虽然界面不是那么好用，但是经过反复尝试，好歹也做完了。
2025-12-22 07:18:39
63
原创 从用户的角度考虑问题
对于自己的产品，如果我们的员工经常"吃狗食"，上面提到的问题就不会出现除非微软员工连"a"都需要解释......但是，这种优秀的传统也有一个副作用，由于我们十分了解自己写的软件，而我们的心理、技术能力和一般用户有很大差别(参见下文提到的"认知阻力")，所以也。很多程序员都没有意识到，用户对那些选项对话框中的种种选择会有很大的畏难情绪，而程序员则觉得自己开发的功能必须有几个高级选项，才显得有水平。设计不同于传统的数学题，是没有唯一的标准答案的。有一颗为用户着想的"同理心"，是好的产品设计的出发点。
2025-12-22 07:17:57
420
原创 用户体验的要素
怎样让用户在第一次使用的时候，少花时间(或者不花时间)在对用户没有价值的部分(如配置软件的基本设置、登录、填写用户的各种属性等)，而把大部分时间花在有实际价值的功能(如完成任务、消费内容、创建内容)上?大家平时都说要向某某大师或某某产品学习，把最重要的功能做好交给用户，把那些无关紧要的功能藏起来，做减法......但是程序员们还是会想着把高级功能"秀"出来。用户头一回来访问你的网站，你要给他们什么样的第一印象?下面的"设计"大胆地做了减法，解决了老年人使用的难题[注释2]:请问，这是一个好的设计么?
2025-12-21 09:17:49
226
原创 如何避免诧异的反应
在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。问:项目开发中后期，开发人员用工具一统计，乖乖，足足xx万行代码，xx千个存储过程，可是每到给客户演示时，却不时出现程序的各个功能相互不配合，不能自圆其说的尴尬场景，Devleader很郁闷，想想自己可是没少加班啊，代码量也够多，可是问题究竟出在什么方面呢?问:每次里程碑结束后，我们向客户汇报的时候，客户总是会惊讶地说，某某功能不是我们当初商量的那样啊，而PM却也同样一脸诧异地说，不对啊，当时咱们就是这么说好的啊，有文档为证。
2025-12-21 09:15:26
324
原创 小强地狱(Bug Hell)
阿超:对，很多问题，甚至是大问题，都隐藏在目前的小强后面，如果一味赶所谓的"进度"，到时候有些小强就变成了大怪物，因为我们已经在错误的基础上搭建了很多新的逻辑和功能，这时再来处理一些历久弥新的小强，就有投鼠忌器的麻烦。如果开发人员的小强(Bug)数量超过一规定值，则此君被送入"小强地狱"，在地狱中，他唯一能做的就是修复小强，直到小强数量低于此阈值。在项目过程中，阈值不宜频繁调整，最好事先宣布阈值。大牛:这是不对的，我们有些小强在你们手头很久了，看似举手之劳，为什么不尽快修复，让我们测试组能继续完成测试?
2025-12-20 01:15:00
355
原创 开发日常-宽严皆误
阿超根据每一个步骤，宽、严各是什么做法和当前团队的情况(势)，列出了一个"宽"或"严"表，如表11-3所示。同时，我们要提高可预见性明确构建大师的职责，公开显示固定的构建时间。经过一个多小时的忙碌，构建终于成功了，但是构建大师问阿超，现在构建成功了，明天呢?(2)宽松的规则和流程，每个人随时可以签出签入，签入时的成本很低，但是签入成功率不高，构建质量低，极端情况下，所有人都可以签入、同步，但是没有人能正常工作。4.提交到TFS上，发现有版本合并冲突，因为在第2、3步时，有人签入了与我的代码有关的新修改。
2025-12-20 01:00:00
226
原创 每日构建(DailyBuild)
阿超:你提到大学的课程，让我想起大学的篮球课。所以有些大学里的高材生到了实际工作中，很多基本功，比如实战中的运球、传球都不灵，他们津津乐道的定点投篮十中八九的功夫也没有发挥的机会了。我当然知道这是遥远的将来的事，但是我总觉得我至少可以做一个软件白领吧，这些构建之类的事情，嘿嘿，是不是要由所谓的软件蓝领来做?在我们的全球调查中，我们发现成功公司中有94%每天或至少每周完成构建，而不成功公司绝大多数每月甚至更少去做构建......当有一个能运行的系统时，即使只是一个简单的系统，(团队的)积极性也会上升。
2025-12-19 01:00:00
251
原创 项目管理日常-构建大师
(3)这时，我们以前做的单元测试和构建验证测试(BVT)就要发挥作用了，每一个开发人员在签入前都要运行所有的单元测试和构建验证测试，确保没有问题后，才能签入。阿超进而建议对于下一个导致构建失败的成员，授予"构建大师"(BuildMaster)称号，构建大师做下面的事。大家发现，最近连续几个构建都不成功，测试组都拿不到新的版本，没法进行测试。(2)签入时，必须从TFS同步下载所有最新的版本再编译，而且个人的签入要做成一个Shelveset，成为原子操作，而不能把一次修改中的所有文件分成几次签入。
2025-12-19 01:00:00
287
原创 开发阶段的日常管理-闭门造车
要有大家自由交流的时间，团队成员们在无拘束的环境中，会更乐意提问和分享，这会比召开正式会议，强迫每个人分享要好得多。在"封闭开发"的情形下，领导也更有可能每小时跑来询问项目的进度，这种团队内部的干扰源，并不会因为团队搬到一个"监狱"里而消失。(3)从TFS来的状态信息，如团队的check-inE-mail，自动分配到一个叫"Check-In"的邮件夹中。小飞:我今天真失败!(2)从团队成员来的、和项目有关的事情，自动分配到一个叫"Team"的邮件夹中。(1)从直接老板来的，发给你一个人的--马上处理。
2025-12-18 07:26:20
323
原创 代码完成(Code Complete)
但是，软件团队毕竟是把"我们认为所有应该写的代码都写了，应该实现的功能都实现了"。一个团队经过几个月的努力，从无到有，从简到繁，把几个月前的远景变成了可以运行的软件，也许我们还有许多问题，但这无疑是很值得庆祝的!代码虽然都写了，但是代码中可能会有很多Bug，各个模块之间的合作还有很多问题。软件的其他工作(如各种类型的测试/国际化/本土化/给用户的文档)都没有完成。代码完成就是指工程师认为所有应该写的代码都写了，所有应该实现的功能都实现了(但未必没有问题)。那么在这一状态的软件就是可以发布的吗?
2025-12-18 07:24:59
412
原创 形式化定义常用的元组，可以称之为元模型吗？
元组是一个纯粹的、抽象的数学结构。形式化定义：一个 *n* 元组是一个有序的元素列表，记作，其中每个aᵢ可以属于任意集合。顺序和长度是定义的一部分。本质：它是一个数据容器或结构单元。在建模中的角色：元组是用于表达具体事实、状态或关系的砖块。例子(1001, “张三”, “销售部”)表示一条具体的员工记录。(“x”, 5)可能表示变量x到值5的一个具体绑定。(3, 4)表示一个具体的坐标点。元组的核心在于它承载了具体的、实例化的信息。元模型是一个“关于模型的模型”。形式化定义。
2025-12-17 01:00:00
738
原创 “checkout an order”用例
最重要的核心步骤（5个）。计算金额 -> 展示并确认关键信息 -> 用户最终承诺 -> 系统永久记录。高度重要的支持步骤（2个）1， 8。第1步是用户侧的起点。第8步是业务运营和客户服务的关键环节，强烈建议保留。可选的实现细节（2个）3， 9。这些是达成非功能性需求（如会话管理、用户行为分析）的手段，可以根据技术架构进行调整或移除，而不会影响“完成订单”这个核心业务目标的达成。最终建议：在设计最小可行产品时，必须确保步骤2，4，5，6，7的绝对可靠。步骤8（发送确认邮件）
2025-12-15 01:00:00
622
原创 Mapping between Use Case Description and Test Case
To enable a test case generation from requirement templates, the relationships between flow-level requirement templates and test cases must be established following these rules. The relationships, as a mapping, ensure systematic and exhaustive coverage of
2025-12-14 07:36:25
331
原创 Software Requirement Description in Use Case
A textual use case describes a task that is performed by an actor yielding a result of business value for a business. A use case specification contains a detailed description of a use case and usually conforms to a template [32]. There are two key attribut
2025-12-14 07:34:55
234
原创 多维时序数据（Multivariate Time Series）的突变点检测
多维时序数据（Multivariate Time Series）的突变点检测是一个极具挑战且重要的课题。与单变量相比，其核心在于如何有效捕捉多个维度间的关系和模式的协同变化，而不仅仅是各个维度自身的变化。以下从核心思想、方法分类、典型算法和实践建议四个维度进行系统梳理。什么是“突变”： 在多维语境下，突变点不仅是单个序列统计特性（均值、方差）的变化，更可能是：相关性/协方差结构的变化： 例如，两个原本正相关的股票开始负相关。系统主导模式的变化： 例如，设备从正常运行状态进入磨损状态，多个传感器的读数关系发生
2025-12-13 07:35:32
965
原创 多维时序数据挖掘
混合方法： 结合深度学习的表征能力和传统方法的可解释性（如深度学习提取特征 + 统计检测）是主流趋势。图时序网络： 对多维关联数据挖掘越来越重要。在线/流式检测： 要求低延迟、高吞吐的算法。领域知识融合： 将物理模型、业务规则作为约束融入数据驱动模型，提升效果与可信度。没有一种方法在所有场景下都是最优的。实践中，需要根据具体问题的数据特性、计算资源、可解释性要求和领域知识来选择或设计合适的方法组合。通常建议从简单、可解释的方法开始，逐步向复杂模型过渡。
2025-12-13 07:25:55
733
原创 时序数据获取事件
通过以上系统性的方法，你可以将看似平淡无奇的时间序列数据，转化为一串具有明确业务意义的“事件序列”，从而为后续的根因分析、决策支持和。：如果有已标注的事件数据，可将问题转化为分类任务（每个时间点是否是事件起点）。将算法检测到的事件与业务日志、已知事实（如运维记录、新闻时间）进行比对，评估准确率和误报率。：用历史数据训练一个预测模型（如ARIMA、Prophet、LSTM），预测下一个值。：计算事件的属性，如开始时间、持续时间、强度、影响维度。：处理缺失值、平滑噪声（如使用移动平均、卡尔曼滤波）。
2025-12-12 12:34:55
841
原创 事件相关性进行预测
利用事件相关性进行预测是一种常见的数据分析方法，核心思想是通过分析历史数据中事件之间的关联模式，推断未来可能发生的情况。若发现强相关性（如相关系数 > 0.8），可设定简单规则（“若A发生，则B发生的概率为X%”）。：A事件发生一段时间后，B事件才出现规律性变化（如政策发布后经济指标延迟反应）。：A事件发生，B事件更可能不发生（如节假日与办公室用电量下降）。：将事件转化为可分析的变量（如事件发生频率、强度、持续时间等）。：A事件发生，B事件更可能发生（如雨天与雨伞销量上升）。
2025-12-12 12:32:20
314
原创 PostgreSQL 数据库的典型操作
VALUES ('钱八', '{"skills": ["Python", "PostgreSQL"], "level": "Senior"}');VALUES ('张三', 'zhangsan@company.com', 50000.00, 1);VALUES (OLD.id, 'status', '在职', '离职');('王五', 'wangwu@company.com', 60000.00),('李四', 'lisi@company.com', 45000.00),-- 在命令行执行，不是SQL。
2025-12-11 07:14:11
597
原创 PostgreSQL 数据库优化
识别：通过日志和找到最慢或最耗资源的查询。分析：使用深入理解其执行计划。优化第一步：检查并优化SQL语句本身。第二步：检查并优化索引（添加、调整、删除）。第三步：检查表结构和统计信息（考虑分区、执行ANALYZE）。第四步：调整相关配置参数（如work_mem第五步：考虑架构层面的扩展（读写分离、分片）。测试与验证：任何优化都要在测试环境验证效果，并在生产环境监控变化。记住，没有放之四海而皆准的最优配置。最佳的优化策略始终依赖于你的具体数据、查询模式、硬件环境和业务需求。
2025-12-11 07:09:26
1424
原创 从Spec到实现
3.在看到初始效果和了解了实现的细节后，小飞开始写设计文档(Technical Spec、Design Document)，写好之后，他可以请同事一起来复审设计文档(复审可选，因为一般情况下任务都不大)。在实现过程中，他又发现了一些意想不到的问题，与PM沟通后，找到了解决方案。8.得到一个可以测试的版本，交给相关的测试人员测试，或者在网上进行某种公开测试，如A/B测试等。10,根据代码复审的意见修改代码，完善单元测试和其他相关文档，然后把代码签入到代码库中。6.创建或更新单元测试。
2025-12-10 11:52:59
494
原创 文学化编程(Literate Programming)
文学化编程(Literate Programming)程序员在写程序的时候，要理解在文档中的需求，同时还要在程序里写相关的注释，这些不同目的的“写作”各有价值，但是一旦需求或程序发生变化，这些不同的文档很难保持同步。些不同方法列举在这里，一方面是要说明，有多种设计软件的方式，它们在不同的历史阶段，在各自适合的范围内能有效地发挥作用。另一方面，我们可以写很多文字，画很多图，写很多公式，还可以口若悬河地倾诉，但是最后在电脑上运行的，是代码。那么，这个笼子里原来的“下有九十四足”就变成了“下有七十足”。
2025-12-10 11:51:42
337
原创 IT疑难杂症诊疗室
记录问题发生时的特定条件（如温度、姿势、是否充电、运行特定程序等）。：拔掉所有外接设备（鼠标、U盘、扩展坞等），在“干净”状态下测试。：电容老化、主板供电模块故障，尤其是使用多年或进过液体的机器。：硅脂干涸、散热鳍片被灰尘堵死、热管失效（内部液体泄漏）。：硅脂老化、风扇积灰、散热鳍片堵塞，导致温度保护触发。：优先排除驱动程序、系统更新、病毒、软件冲突等问题。：系统突然完全卡住，鼠标键盘无响应，有时伴有电流声。：合盖后，再打开屏幕一片黑，必须强制重启。：部分按键无效、连击，或触摸板光标乱飞。
2025-12-09 08:05:54
703
原创 C盘清理技巧分享
搜索并运行“磁盘清理” → 选择磁盘 → 勾选可删除项（如临时文件、缓存）。使用文件粉碎工具（如Eraser、BleachBit）防止恢复，保护隐私。如果不确定某文件/文件夹的作用，先搜索确认再操作，或使用专业工具辅助分析。格式化会清空整个磁盘，仅适用于无需保留数据的情况（如重装系统前）。设置 → 系统 → 存储 → 开启“存储感知”，自动清理临时文件。控制面板 → 程序和功能 → 卸载不用的软件，避免手动删除残留。在清理前，将文档、照片、工作资料等备份到外部硬盘或云盘。
2025-12-09 08:01:58
436
原创 软件工程练习题COMET
(d)对系统的一个子集中的类进行单元测试和集成测试5.增量软件集成过程中会进行以下哪项活动?以下问题与本书中描述的软件建模和设计方法(COMET)相关。(d)系统的功能性需求通过用户访谈来确定2.分析建模过程中会进行以下哪项活动?(b)对系统的一个子集中的类进行详细设计、编码和单元测试。(a)对系统的一个子集中的类进行详细设计和编码。(c)对系统的一个子集中的类进行编码和单元测试。(c)集成测试每个软件增量中的类。(b)单元测试每个软件增量中的类。(d)系统测试每个软件增量中的类。
2025-12-08 16:05:43
232
原创 软件工程练习题
(b)隐藏很可能发生变化的设计决策(d)将数据封装在一个类中。(b)在类间共享和复用代码的机制(d)在类间隐藏信息的机制。(c)被一个类提供的函数或过程的规约和实现。(b)操作的函数或子例程(d)对象的接口。(b)被一个类提供的子例程的规约和实现。(c)一组数据和对数据进行操作的过程。(a)被一个类执行的函数的规约和实现。(d)被一个类提供的接口的规约和实现。(c)具有相同特征的对象的集合。(d)具有不同特征的对象的集合。4.什么是类的操作(或方法)?(汙钢b)类提供的操作的规约。
2025-12-08 16:04:14
263
原创 软件体系架构师的角色
然而，在大型项目中，由于有太多的高层次问题要架构师花费大量的时间来思考和决策，因此，大型系统的架构师应注意避免拍泥于实现细节，而造成整体体系结构的设计受损。此外，架构师还必须经常审查和确认系统级的工程组织所提出的需求，以及开发团队所提出的设计。软件架构师对项目管理、其他技术领导、系统工程和开发者而言，起着一个重要的沟通者的作用，架构师在帮助一个团队成员找到恰当关系的同时，也需要为其他团队成员翻译技术资料。对这些风险，应该提供一份减少风险的计划，这些计划无论是正式的或者非正式的，都是架构师的责任。
2025-12-07 09:26:19
470
原创 时间位置嵌入本文使用正弦和余弦函数结合嵌入维度进行编码
在时间序列模型中（尤其是基于Transformer的架构），如何将编码为模型可理解的向量形式。这是一种关键的技术。
2025-12-07 01:00:00
271
原创 传统注意力机制在处理复杂时间序列数据时的一个核心缺陷
高频音符（瞬时波动）一段旋律的推进（局部趋势）重复出现的主题乐章（周期规律）传统的全局注意力机制，相当于让每一位乐手去倾听整首曲子所有时间点的声音，然后判断哪些声音对自己最重要。这虽然理论上可行，但效率低下，且乐手很难清晰区分出“当前小节的高频伴奏”、“上一乐章的旋律线”和“十分钟前出现过的主题”各自对自己的影响。分解式架构：先显式地将序列分解为趋势、季节性和残差成分，再对各成分分别建模（如Autoformer、FEDformer）。多尺度注意力。
2025-12-06 01:30:00
858
原创 时间序列季节性
在时间序列预测分析领域，（Seasonality）是指数据中出现的，这种模式以重复出现，通常与日历或自然周期相关。它是时间序列分解中的核心组成部分之一。
2025-12-06 01:15:00
394
原创 制造业非线性的累积效应的例子
跨服务依赖链是传导路径：问题不再局限于单一设备或流程，而是通过数据流和决策流在MES、ERP、WMS、仿真、调度等多种服务间高速传导和放大。智能算法是加速器：基于数据的AI/ML服务会学习并固化偏差，甚至主动做出加剧问题的决策（如案例一的排程），让累积过程更快、更隐蔽。系统复杂性掩盖早期信号：在达到临界点前，系统的冗余和补偿机制可能掩盖问题，或将问题分散表现为不相关的“小故障”，使得传统线性监控手段失效。爆发后果具有全局性和颠覆性：最终结果往往不是某个环节的“大问题”，而是整个网络化生产系统的。
2025-12-05 01:15:00
817
原创 非线性的累积效应
非线性的累积效应”揭示了世界运行中一个深刻的真相：许多重大变化并非一蹴而就，也非匀速渐进，而是微小力量长期积累，最终在关键节点上引爆的质变过程。它强调了耐心、远见和对系统脆弱性/潜力的深刻认知。
2025-12-05 01:00:00
440
原创 软件需求变更
根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。其实，需求变更也是软件开发过程中开发人员和管理者们最为头疼的一件事情，而且有的项目由于需求的频繁变更，又没有很好的变更管理，最后导致项目失败。该委员会负责评估和确定需求变更。
2025-12-04 09:40:32
329
原创 软件需求验证
每一项需求都必须准确地陈述其要开发的功能，做出正确判断的依据是需求的来源，如用户或高层的系统需求规格说明。验证需求是否是可跟踪的，应能在每项软件需求与它的“根源”和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的粒度好(6ne-grained)的方式编写并单独标明，而不是大段大段的叙述。需求验证是一种质量活动，需求规格说明提交后，开发人员需要与客户对需求分析的结果进行验证，以需求规格说明为输人，通过符号执行、模拟或快速原型等途径，分析需求的正确性和可行性。
2025-12-04 09:39:06
347
原创 AUGMENT, NEUER REPLACE, NATURAL LANGUAGE
AUGMENT, NEUER REPLACE, NATURAL LANGUAGEIn an effort to reduce ambiguity in requirements, software developers oftendecide to use a notation that is more precise than natural language. This isof course, commendable in that ambiguity is reduced (Principle 5
2025-12-03 07:48:03
227
原创 REDUCE AMBIGUITY IN REOUIREMENTS
Most requirements specifications are written in natural language. Naturallanguages suffer from inherent ambiguity due to the imprecision of thesemantics of words, phrases,and sentences. Although the only way toremove all ambiguity from the requirements is
2025-12-03 07:47:19
378
测试用的需求文档Methodology for Qualifying Safety-Related Electrical and
2025-04-06
计算机科学与软件工程中的统一大学库存系统（UUIS）功能需求与用例分析
2025-03-13
电子商务系统软件需求规范（GAMMA-J在线商店V1）详解
2025-03-13
水文管理与用水追踪系统的软件需求规范-基于地理信息系统的技术应用与需求分析
2025-03-13
Visual C++ MFC例子，从基础例子到提高，总共11个主题
2024-08-13
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人