软件设计的建议(软件设计的问题)

2023-03-23 00:09:01舞蹈037

今天给各位分享软件设计的建议的知识，其中也会对软件设计的问题进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

1、如何开发出一款教育类APP软件
2、智能硬件产品的软件设计
3、提高软件设计能力
4、软件设计原则有哪些
5、如何从一个完全不懂软件设计的人，开始学软件UI设计

如何开发出一款教育类APP软件

简单点来说，要视手机APP的需求及质量而言，价位一般在几千到十几万左右，更高端的价格更高。

今天，我们就来详细分析一下这个问题，请继续往下看吧。　

一、APP开发款式分为固定款和定制款，两者的价格均不相同

固定款：是指直接套用已有的、现成的APP固定模板，报价是固定的，所需要的功能也是固定的，缺点就是客户拿不到源代码，也不能根据企业需求进行定制，由于源代码是封装的，如果企业以后想进行功能升级或系统维护的话，也不能够实现，只能重新开发一个新的软件。

固定款的APP开发时间短，约2~3日的时间即可完成，费用大约在几千到几万之间。

定制款：定制款是指APP的功能全部重新开发，过程比较繁琐，需要美工、策划、APP开发（前台/客户端/手机端）、后台程序员等工种协同完成，大型的、功能复杂的APP甚至需要数十人的团队。

由于APP的功能和设计都是定制的，因此价格会高些。定制款的开发时间与开发价格是成正比的，开发时间长，大约在两三个月甚至不定的周期里才能完成，而费用大概在几万甚至十几万左右。

因此，想要知道开发一款手机APP需要花费多少钱，企业主首先必须把APP的详细需求和功能告知APP开发公司，开发公司才能报出一个合理的价格。

二、手机APP平台不同， *** 成本也不一样

现在市面上流行的手机APP *** 平台主要有两种一般包括两种系统：安卓系统（Android）和苹果系统（IOS）。

一般来说， *** 苹果系统的手机APP软件费用要比安卓平台的贵一些，因为苹果公司对苹果平台的封闭性和手机APP开发语言Objective-C的难度，都让APP开发者加大了苹果系统手机APP开发的难度。

三、APP *** 成本包含参与人员的工资

通常情况下，开发一款APP需要产品经理、客户端工程师、后端工程师和UI设计师各一名，这已经是 *** 手机APP应用软件比较精简的配置了，所以这些参与人员的工资也是包含在APP *** 成本当中的。这些工作人员的月薪加起来可能都会超过4、5万元。

四、APP开发公司的所在地

需要注意的是，同样实力的APP开发公司，在不同的城市也会导致APP的成本费用高一些

软件设计的建议(软件设计的问题),第1张

智能硬件产品的软件设计

我一直相信努力会有回报，一直在公司推的扩展器APP项目终于做起来了。目前UI，UE已经完成，软件开发和APP开发的接口也对好了，就等排期进行开发了。我觉得自己的运气也是极好的，本来一个APP项目是很难立起来的，这期间经历的挫折和打击也不少，还好搭着costdown项目的顺风车一起做了起来。本文主要讲讲整个硬件产品的软件设计中自己的经验，虽然以扩展器为例，但是这些点适用很多智能硬件产品的软件设计了。

既然APP都要做了，则索性将PC端和H5端都进行了一次迭代，由于接手过来的时候PC端和H5端产品都已经做了一个初版，但是都没有相关的文档，所以自己全部重新整理了一遍PC端，H5端的文档。当写一个新的产品或者功能的prd的时候，我是可以根据自己的逻辑和思路一气呵成的，但是这个我需要在同一个文档里既整理出现有产品的内容还得加入新的想法进行改进。这就要求我得先对已有的功能逻辑完全了解，然后思考这个逻辑是否合理，有没有更好的方案。更奇葩的是，有些逻辑我觉得是混乱的，在询问之前团队时，他们居然说当时有些异常情况没有遇到，没有去做相关的测试，所以没有梳理相关逻辑。因为项目的推动不容易，主要是因为开发资源比较紧张，在和开发商量的时候答应过开发，PC端和H5端的升级会尽量减少开发的工作量。因此在梳理文档的时候，只是整理现有逻辑，修改不合理的逻辑，梳理之前团队没有想的逻辑，新功能一个都没有添加。关于PC端和H5端这块，我只想给出以下建议：

遇到中途接手的项目，并且没有相关文档可以参考的时候，三点建议：

之一：一定是需要把已有的逻辑了解透彻，记录下逻辑还有优化的点以及逻辑混乱的点，自己先梳理一遍之后再去和现有的开发团队对一下有没有什么问题；

第二，考虑到开发也是根据现有的程序做修改，在文档中把有改动的点一定要做标记，清楚描述现有逻辑是怎样的，修改后是怎样的，这样方便程序员查看；

第三，除了有些逻辑进行了相关改动，为了更好的用户体验，交互方面也做了些改动。坑爹的是，翻看公司之前的UE和UI资料，发现做出来的产品和资料对不上，这可苦了UE和我了。我给UE把整个产品操作流程录了下来方便她对着现有做出来的查看，然后把要修改的地方在文档中标记出来，拜托她对着标记的地方做相应的修改。最后我再把她做出来的UE图仔仔细细对好几遍，有不对的地方得记录下来拜托她再修改，这还得来回好几次。

虽然过程繁琐了点，但是比推项目的时候开心多了。而且这样一来，我相当于把一个硬件产品所需要的软件设计全部做了一遍。虽然说扩展器的功能比较简单，但是能把架构和细节都过一遍，也学到了不少东西。毕竟之前做路由APP的时候全部做的是功能点，没有一个整体的概念。

这部分主要是根据自己做扩展器APP的经验，介绍一下在设计智能硬件产品APP的时候需要注意的部分重点。智能硬件产品APP不同于纯互联网APP，它的设计需要考虑的端比较多，每一个逻辑都需要考虑到所有的端的情况，不同端之间会相互影响，不同的 *** 情况又会对不同的端造成不同的影响。所以那个情况多呀，异常多呀，有些功能稍微复杂点的写出来的prd快赶上一个APP了。今天呢，不谈这些细节，细节还是放在具体的功能设计里面去说比较合适，今天只说在新做一个硬件产品APP时需要考虑的切入点。

一般来说，对硬件产品APP而言，重要的有如下模块：

接入，首配，工具

对于一个刚起步的硬件产品APP来说，其中最重要的是接入和首配，只有简易快速的配置连接硬件，才谈的上控制硬件，即工具和APP的其他功能设计。

接入主要考虑的是APP如何识别出硬件产品，识别是不是自己公司的产品（只有自家的产品才能进行通信控制）以及是自家公司的哪个产品（不同的产品，其首配，工具等等很多功能都是不一样的）。由于公司的硬件产品比较多，更好的是能够将相同性质的硬件产品集成在同一个APP里面，这样既方便产品的开发，用户体验也会更加友好。扩展器同路由器一样同属 *** 产品，再加上扩展器本身就需要搭配路由器使用，因此我所负责的扩展器APP是直接集成到现有的路由APP里。识别是否为自家公司的产品好做，一般待配置产品的SSID（ *** 名称）都是带有自家公司的名称的，根据SSID就可以直接判断了。那如何识别这是一台路由器还是一个扩展器呢？连接上设备的 *** 后，路由器是有IP地址的，APP可直接通过访问IP发送消息来确认是路由器。但是扩展器只有在扩展成功后才会有分配的IP，而且还是变化的，因此不能使用和路由器一样的 *** 进行识别。产品处于待配置状态时会广播一些字段，其中就有MAC地址，原以为可以通过对Mac地址进行管控，直接将一段Mac地址对应一类产品，这样就可以直接通过Mac地址进行识别产品类型。然而首先我们公司并没有做Mac地址的管控，其次APP通过广播接收的Mac地址信息会有一定的不准确性，因此这种 *** 不可行。但是广播出来的字段又没有其他有用信息可利用了，所以又回到了SSID上，我们决定给SSID加上后缀名，表征它是一个扩展器。因用户在首配和无线设置中是可以修改SSID的，为了始终能够识别（除了首配的时候需要进行识别，在用APP切换设备管理的时候也需要对连接设备进行识别），后缀名不能让用户改动，这个我们在交互层面上做了一定的设计，而在理解上，则参考Word之类的文档名称一样，只能修改名称，不能修改后缀名。从SSID上进行识别只是一个初步识别，在初步识别后还会通过尝试通信让扩展器发送一个产品类型的字段进行确认。

这样整个识别接入的逻辑才算完整，开发做起来相对简单，用户体验也没有太大影响。

不同的产品的首配流程是不一样的，这里只谈一些共识点。首配需要首先检测是否首配过，检测 *** 在了解后略微有点low。主要是根据WiFi名称是否被更改过以及是否有设置密码来判断。当然，若恰好某台配置过的路由器既没有修改WiFi名称还没有设置密码，那不好意思，我们判断不了，可能需要重新配置一次了。整个首配流程在设计的时候一定要简单并且防呆工作做好，不然一步错导致步步错就会带来极差的用户体验，而首配的失败会让用户对整个品牌和产品的好感度消失。无论是在路由配置还是扩展器配置中，首配基本上都是“一气呵成”的，也就是把所有的设置项都选好后记录下来，中间没有任何生效的点，只有最后一步才会将所有的设置生效。而有一点不一样，就是管理员密码的设置是直接生效的。在体验产品的时候会发现，在保存管理员密码后不进行接下来的配置，退出后再次进入则需要输入管理员密码；而且输入后不能进入首页（也就是不能），而是进入继续配置的页面。为什么要提到这些，因为有两个方向的考虑点，一是管理员密码有没有必要和接下来的配置分离开，二是用户就是不想配置连网就想使用工具控制设备的场景怎么处理。PC端现在做的还是分离和不能进入，而APP不同的是，用户在输入管理员密码后可以跳过配置，直接进入首页，因为考虑到APP是有与硬件不相关的功能（比如社区）和账户体系（比如我）。分离是为了设备管理的安全性着想；不能进入考虑的是大部分场景：没有扩展连网，设备的意义不大，所以还是尽量引导用户去配置完成。

以上几点是首配中比较容易混乱的大的逻辑点，其他的步骤是根据不同设备的连网需求而有所不同的，这个里面的细节也是非常的多，本文就不做过多的描述了。

不得不说，文章排版有点.......（不过内容可是真真切切的的实战干货）我实在不想把时间花在排版上，因为还有好多东西要学，好多内容要尽快输出。此时的我已经换了个部门，现在已经不是硬件产品经理了，目前是一名社区产品经理。所以很多东西要尽快学习熟悉起来，不然要被人怼死。以后输出的和硬件相关的产品设计文章可能不多了，社区产品相关的文章请拭目以待。

提高软件设计能力

首先设计能力的提高是循序渐进的，主要方式当然是学习他人 *** /经验/及实践。建议如下步骤：

1、尽量熟悉某一类软件的基本设计思想；

2、明确需求，尽量贴近客户，这样在设计时把握准确；

3、学习软件设计理论知识；

4、多参考该类软件的设计资料，前人的设计文档；

5、最重要一点，做任何事，尽量计划好和规划好后，再行动，力争事半功倍。

软件设计原则有哪些

七大设计原则

开闭原则

依赖导倒置原则

单一职责原则

接口隔离原则

迪米特原则

里氏替换原则

合成复用原则

设计模式-创建型模式

工厂 *** 模式

抽象工厂模式

建造者模式

单例模式

原型模式

设计模式-结构性模式

适配器模式

装饰者模式

*** 模式

外观模式

桥接模式

组合模式

享元模式

设计模式-行为型模式

策略模式

模板 *** 模式

观察者模式

访问者模式

迭代器模式

责任链模式

中介者模式

解释器模式

状态模式

命令模式

备忘录模式

软件设计原则介绍

所以，可以说软件系统是连接需求分析、硬件系统以及使得系统实现的桥梁，对软件的设计应首先了解软件设计的设计原则。

设计原则

(1)可靠性

软件系统的规模越做越大越加复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。

(2)健壮性

健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。

(3)可修改性

要求以科学的 *** 设计软件，使之有良好的结构和完备的文档，系统性能易于调整。

(4)容易理解

软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和 *** 的适当运用。

(5)程序简便

(6)可测试性

可测试性就是设计一个适当的数据 *** ，用来测试所建立的系统，并保证系统得到全面的检验。

(7)效率性

软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。

(8)标准化原则