原型设计

1、什么是好的产品原型 从2017年起开始接触产品设计这一领域，也陆续兼职了公司几个项目中的产品经理职责（主职位是技术架构），总结一下在产品设计过程中的一些细节吧。 首先，什么样的产品原型算得上一个好的产品原型呢？可能很多人会从高保真程度，交互还原，文档注释等方面给出不同的评价标准，但是我想说的是，必须先明确产品原型面向的是哪类人群，然后针对性的满足产品原型阅读者的需求，这是判断产品原型好坏的根本标准。 把所有查看你的产品原型的人看作为你的用户，分析用户需求。 这里以我自己的经历 举例 ： 阅读者 需求是什么 怎么实现 老板/客户/需求方 实际中我的第一用户是我的老板，可视作产品需求来源，最终的决策者； 希望看到一个产品原型完整地将他对于产品的想法以可视化的形式呈现出来，并在此过程中体验产品效果，验证想法，完善细节，最终达到一个确定的”产品雏形“ 形成整体的信息架构图、分层业务逻辑图，此用来梳理产品的核心逻辑 形成初步的产品交互原型，包括涉及到的终端，核心的功能操作，让产品想法初步变为一个可操作，可讨论，视觉化的体验 UI设计师/交互设计师 根据原型去设计视觉，交互体验 走到这一步说明产品经过了第一阶段的初步确认，起码达到了第一个版本。 针对设计师用户，需要定义出整个设计规范，设计风格，以及交互要求。视自身的axure或者其他原型工具的掌握水平，可做高保真的交互原型

Alpha版本第一周小结 姓名 学号 周前计划安排（PM填写） 每周实际工作记录（要求见3.项目阶段检验作业） 自我打分（百分制） HMQ 061123 规划项目的进程，编写项目的计划书以及对协助队员解决技术困难 对项目进程进行了合理的安排，编写了团队的需求分析说明书，概要设计说明书和详细概要说明书。 93 GA 061120 技术支持、编码及测试工作以及协助原型设计，提供相关的资料 帮助了HXH进行原型设计，为其提供相关的治疗 92 GZJ 061121 负责软件需求的分析、功能的确定，编写一些文本，制作答辩PPT等 制作了两次答辩app， 90 HZZ 061122 编写代码，规范代码，在前期进行一些数据的处理和系统设计，和设计原型界面 完成了原型界面的初步设计 91 HXH 061124 团队主要的开发人员，负责主要的代码编写以及原型设计。 完成主要功能的原型设计 95 来源： https://www.cnblogs.com/ppppppig/p/11811444.html

《软件工程基础》作业：Alpha版本第一周小结 这个作业属于哪个课程 <18级软件工程基础> 团队名称 Alibaba国际懂事会 Part1. 计划安排及工作记录 --团队名称： Alibaba国际懂事会 --附表如下： 团队成员 学号 团队身份 周前计划安排 每周实际工作记录 打分 WHY 3104 队长 规划项目进程，组织团队会议、给成员分配任务，参与文档拟写以及原型设计的测试和审核。 组织了会议，规划了项目的进程，并分配了任务，负责拟定并制作了本次调研的问卷，参与了最后文档的修订工作。 95 SH 1315 队员 答辩PPT汇报工作以及需求分析的拟定。 出色完成了答辩汇报并且在PPT中也很好的体现了我们的调研结果，效果完美。 99 TSK 2208 队员 根据需求分析进行相应的原型设计概要计划，并负责PPT资料整合。 和SH同学任务对接非常完美，对最终的调研结果进行了整合，帮助SH同学出色的完成了PPT。 98 YYT 1401 队员 负责团队项目界面设计工作，同时负责原型设计。 界面设计正在完善，并帮助YJ和ZLP实现本考勤管理系统的相关功能，任务完成出色。 98 YJ 1307 队员 负责项目调试及原型设计工作。 完成了部分原型设计，并实现了相应的功能，和YYT、ZLP任务对接出色。 98 TR 1204 队员 主要负责项目的技术支持，文案拟写等工作。

Alpha版本第一周小结 # 任务分工 姓名|学号|任务 ---|:--:|---: WSP|2129|结构设计，负责产品功能的分工，构思结构。撰写推广文案。 PT|1501|文档和汇报PPT撰写。 THL|1205|原型设计，对各个功能模块进行实现。 SL|1328|老师客户端界面设计，与原型设计一起工作。 YZH|1105|学生客户端界面设计，与原型设计一起工作。 RXY|1203|原型设计，对各个功能模块进行实现 NXJ|1202|负责产品的推广，负责产品的美化。 ZZY|2223|负责最终产品的审查，测试。 原型设计 进度安排 1-2周完成用户调研，确立设计方案 3-5周进行原型设计 5-6周进行产品审查 7-8周进行产品推广 来源： https://www.cnblogs.com/simple5960/p/11803125.html

本文首发于我的个人博客 ： http://cherryblog.site/ 前言 js 中的类型检测也是很重要的一部分，所以说这篇文章我们就来讲一下怎么对 JavaScript 中的基本数据类型进行检测。其实这也是在读 Zepto 源码中学习到的，所以阅读源码对我们的提升还是很有帮助的。本文基于参考了前辈们的文章之后个人理解此文写的有不当的地方，请各位大佬指正。 其实常规方法主要有四种 typeof instanceof Object.prototype.toString construcor 其实这四种方式归根结底就是两种思路： 根据数据类型判断（1，2） 根据构造函数判断（3，4） 前置基础 再看 Zepto 之前看了 慕课网一个老师的视频 ，一共一个小时左右，开了快进估计也就 45 分钟左右。只是讲了 Zepto 的架构和设计，没有详细的将每一个方法，初看之前可以看一下，对 Zepto 有一个大概的印象。 原型与原型链 其实这部分真的是老生常谈的问题，但是每一次听其他人都有新的收获。 真的是不想写这部分，但是自我感觉整体思路比较清晰 ，所以推荐大家阅读一下。 Zepto 整个的设计思想其实是基于 js 的原型链。关于原型链，这个老师讲的比较清晰，需要记住三句话： 每一个函数，都有一个 prototype 属性。 所有通过函数 new 出来的对象，这个对象都有一个 _

原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。 介绍 意图： 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 主要解决： 在运行期建立和删除原型。 何时使用： 1、当一个系统应该独立于它的产品创建，构成和表示时。 2、当要实例化的类是在运行时刻指定时，例如，通过动态装载。 3、为了避免创建一个与产品类层次平行的工厂类层次时。 4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。 如何解决： 利用已有的一个原型对象，快速地生成和原型对象一样的实例。 关键代码： 1、实现克隆操作，在 JAVA 继承 Cloneable，重写 clone()，在 .NET 中可以使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。 2、原型模式同样用于隔离类对象的使用者和具体类型（易变类

克隆羊问题 现在有一只羊tom，姓名为: tom, 年龄为：1，颜色为：白色，请编写程序创建和tom 羊 属性完全相同的10只羊。 传统方式解决克隆羊问题 1) 思路分析(图解) （类图中少了 一个 color 属性） 2) 代码演示 public class Client{ public static void main(String[] args){ //传统方法 Sheep sheep=new Sheep(“tom”，1，“白色”)； Sheep sheep1=new Sheep(shep.getName()，shep.getAge()，shep.getColor())； Sheep sheep2=new Sheep(shep.getName()，shep.getAge()，shep.getColor())； Sheep sheep3=new Sheep(shep.getName()，shep.getAge()，shep.getColor())； } } 传统的方式的优缺点 1) 优点是比较好理解，简单易操作。 2) 在创建新的对象时，总是需要重新获取原始对象的属性，如果创建的对象比较复杂时，效率较低 3) 总是需要重新初始化对象，而不是动态地获得对象运行时的状态 , 不够灵活 4) 改进的思路分析 思路：Java 中 Object 类是所有类的根类，Object

国庆假期后的第一周： 总体回想起来，没有什么值得念叨的。唯一可以记录下的估计也就是周五看到的新项目的流程问题。 那是一个小程序项目，原型是一个业务上的非技术人员画的，很是难看且漏洞和逻辑上错误不少。可笑的是，领导在给我们开发人员讲完新项目情况或者说需求的时候，效果图已经快设计完了？所以说我们在听完需求，开始了解已有原型和效果图的时候，是有多么的不爽和气愤，对流程错误的不爽，对白费设计人员工作成果的不爽，因为效果图再好，也肯定是基于原型来画的，原型就漏洞百出，效果图再好也得重做。 另外还得再说一次，原型出来后，必须由后端人员审查确定、前端人员确定、领导审阅、客户审阅通过后，再交给界面设计人员进行效果图设计，效果图出来后直接给客户确定就好了，客户说OK后，API、后台管理、前端的就可以开始了，其中后台管理可以更早的开始。 第二周： 总体来说，这周就干了一件正事，那就是按照自己的理解画了个项目原型，虽然不一定采用但起码能进行多人沟通的起点，以及反映出一些问题，以便后续进行改进优化。大伙一起明确需求只是口头或者脑袋里交换意见达成一致，但太抽象，将这些抽象反映到实实在在的原型上，这样大家就能更清晰的认识到需求到底是啥样，或者跟自己想象的有什么不一样的地方，或者发现自己或者别人有漏洞的地方。进而促进团队之间达成更进一步的统一。 另外这周还和一个运营的同事交流一个之前项目后台系统的优化问题

1、产品人员设计完原型和文档后，召开需求评审会，参会人员有开发，测试，产品。需求评审后之后，会产生一个完善之后的原型和需求文档。 2、测试组负责人需要依据需求文档，项目周期、项目特点、工具、人员安排制定测试计划。 3 4 5 6 7 8 9 10 11 转载请标明出处: Android 测试的流程（工作流程） 文章来源: Android 测试的流程（工作流程）

为了指导软件开发，可以用不同的方式将软件生命周期中的所有开发活动组织组织起来从而形成不同的开发模型。 瀑布模式 瀑布模型严格遵守软件生命周期各阶段的固定顺序:计划、分析、设计、编程、测试和维护，上一阶段完成才能进入到下一阶段，整个模型像一个飞流直下的瀑布一下，如图所示 特点: 阶段间具有顺序性和依赖性 前一阶段完成后,才能开始后一阶段 前一阶段的输出文本为后一阶段的输入文本 推迟实现的观点 质量保证: 每个阶段必须交付出合格的文档 对文档进行审核 缺点: 开始需要把需求做到最全 惧怕用户测试中的反馈,惧怕需求变更 过于理想化缺乏灵活性 螺旋模型 限制条件: 适应于内部的大规模软件开发:螺旋模型强调风险分析,许多客户都无法接受和相信这种分析因此 适合于大规模软件项目(执行风险分析将大大影响项目的利润,进行风险分析就毫无意义) 软件开发人员应该擅长寻找可能的风险,准确地分析风险,否则将会带来更大的风险 优点: 设计上的灵活性,可以在项目的各个阶段进行变更. 以小的分段来构建大型系统,使成本计算变得简单容易 客户始终参为保证了项目不偏离正确方向以及项目的可控性 客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品. 缺点: 很难让用户确信这种演化方法的结果是可以控制的.建设周期长,而软件技术发展比较快