参与开发的直接人员（即开发团队）数量在3~25人
开发时间在3个月~18个月的软件项目
代码行数5000~75000行
子程序数量300~3500个
1、软件开发管理的任务
软件开发管理的真正任务是团队成员的智能充分而适宜地发挥，并有效地投注在创造软件的活动中。也就是说：合理配置各种资源（管理人员、工程师、设备、软件、制度、时间）确保软件开发的有效进行。最起码需要避免个体智商120，所开发的软件象智商60的人开发的软件——确保创造性智能活动保持创造性张力并取得创造性成果。
2、项目管理的根本焦点
项目管理的根本焦点集中在T、Q、C、S上，即：开发进度、特性与品质、成本、顾客服务。其中最核心的是开发进度、特性与品质两个方面。其它一切管理工作都必须围绕这些焦点进行。
3、中小项目软件开发的组织设计
有效的组织设计是进行项目开发的前提。大部分软件开发项目都是中小软件项目，或者说都可以应用本处所说的项目管理原则，中小项目软件开发的组织设计主要是设计参与项目开发的各种角色及其权利、责任和这些角色之间的关系。
参与中小软件开发项目人员，按角色可以分为五种：
⑴项目经理
项目经理也有时被称为产品经理、品牌经理、项目负责人、项目总监。 项目经理的职责是：
领导团队定义出一个成功的产品
引导团队对产品注入深切的期望和信念
带领团队将理想实现，变成可预见的产品诞生
原则1：在项目经理可以对团队有任何价值之前不应该有任何直接的控制权——要权威不要霸权，充分授权是项目成功的必要条件。
项目经理是软件开发的核心任务：他具备技术背景，拥有建构软件的技术领导能力，他有擅长沟通和倾听，是维系团队灵魂的关键人物。
项目经理的具体工作是：负责制定开发日程、配置资源、与外界沟通。项目经理必须担负着保证团队士气、营造共同美好前景的责任，也必须在困难出现时通过坚强的信心和必要的资源调整来确保士气和进度。
⑵系统分析员
进行技术规划和开发设计。
⑶程序开发员
写程序、抓错虫。
⑷品保人员
测试、评估软件品质
原则2：品保人员与开发人员比例不低于1：2
⑸文档编制与使用者培训
撰写文档，以便用文字的形式正确表达软件的功能和使用
原则3：软件文档的编写量要适中，一般要作到详细，但是文档量上不要超过这个标准：1页程序代码的文档数量不要超过1页。
详细划分应该包括：
项目主管
产品主管
构架者：负责在设计和实作层次整合软件概念
使用者接口设计者
使用者联络人
开发人员
品管/测试人员
开发工具制作者
版本建立管理者
风险管理者
使用者文件编修专门人员
讨论：注重开发程序与士气的关系
4、软件开发的金三角
软件开发的核心是：特色（产品与其品质）、资源（人和钱）和时间。
原则4：金三角警惕
加派人手？小心但不禁止！
追加预算？可以但是别掉进无低洞！
增加特色？谨慎但不禁止！
推迟时间？可以但是千万小心！
5、里程碑与检查点
里程碑（基线、基点）则是一个软件配置项在生存周期内的某一特定时刻正式设计并固定的静正式批准的版本，不管媒体如何，它是阶段性目标（可以认为是一个中间产品）。配置项是一个配置中的实体它满足一项最终使用功能，并能在给定的参考点上单独标识。里程碑应该是团队阶段性工作完成的标志，对于任何一个里程碑都应该给于认真的检查、审定和批准。 一般里程碑应该少于两个月，多于三个星期，里程碑给团队带来成就感，提高士气。通常必须含有的里程碑为：
里程碑1：调研 审定对象：调研报告
里程碑2：需求分析 审定对象：需求规格说明书、结构设计报告
里程碑3：数据分析 审定对象：数据字典
里程碑4：概要设计 审定对象：概要设计报告
里程碑5：详细设计 审定对象：详细设计报告
里程碑6：编码 审定对象：各配置项编码、测试报告、产品文档
里程碑7：发布 审定对象：用户使用报告、产品文档、总结报告
警示：对于每个错误列出的需求，将在下游开发中付出高达50~200倍的修正代价
原则5：里程碑必须设置并且设置时间不应是团队感到太长也不应感到太短，它必须有进行正式审定的衡量标准（零缺点里程碑）。
原则6：除非任何一个人都到达了里程碑否则就没有达到，即：团队中最后到达的决定着团队的效率。
在里程碑中间应该设置大量的检查点，这些检查点应该有可以审查的不管是何种媒体的资料。检查点应该细分到一旦检查点出现问题不至于无法在时间上挽回，一般来说一周一个检查点是不长的。任何人都应该有检查点。
原则7：特殊的软件程序设计师可以作出一些无法想象的创举，掀起一波技术的飞跃，但是他绝不会出现在矢志如期推出产品的开发团队中。如果这种没有检查点的人，他是最可以破坏产品的开发者。
6、成功的项目管理者与成功实施项目管理的项目
作一个成功的项目管理者：
不耻下问
给组员设定短期目标
建立长期计划
建立评核制度
成功实施项目管理的项目组应该是：
进度刚好可以完成，适度紧张而可以完成
团队和组员士气高涨
成员富有思考、乐于沟通
7、有效率的工作会议
如果以下超过3个的回答是是的话，那么工作会议的质量就需要主管去考虑了，长期下去必将损害士气、决策质量。
是否有人没有发言？
是否出现了20%的人发言超过了80%的情况？
是否有这种情况：本次议定的题目，而在会中说下次再说吧？
是否发言需要主管点名？
会议没有引导者？ l 发言是对人而不是对事？
主管是威胁多于鼓励？
是否有人有话但没有说？
8、需方委托得项目开发中的若干实际原则：
原则8：顾客的需求是工作的核心，任何所谓天才的设想必须征得顾客赞同。
原则9：持续得改善比一次性改善更能提高顾客得满意度，更好得是对开发方好处更大，但是牢记顾客关心的需求绝不可推迟。
原则10：能够成熟的技术莫要用不成熟的技术，叫的最响的不一定是最好的，不成熟的技术不要流给顾客，留在实验室或作BETA版吧
软件开发中的几个常见问题分析
如果你在软件开发中遇到了下列问题，那么以下的建议也许对你有帮助。
团队成员为什么不善于思考？表现为不发表自己的简介、不与他人进行建设性交流
软件管理在沟通体制上出现了问题，这些问题可能是以下问题的一个或多个：
成员认为没有人重视自己的想法
没有好处，也许给主管的想法不一致，主管是不能接受自己建议和批评的
成员认为应该主管告诉他一切
管理者从来都是只管发号命令
解决办法：
A.每一个成员的建议都是重要的
B.与主管不同的意见更值得重视和讨论
l) 主管告诉成员做什么，不要问怎么做——除非成员向你询问，那么做下来一起讨论
2）为什么软件的进度老是落后或者功能上老是不能令人满意？
也许你会向软件开发者或系统设计者找原因——基本上你可能是失望的。实际上你第一个要看的品保人员：人数够不够？确实参与设计了？