[Group Weekly Plan] 2005 12/1-12/9 需求设计 UNICODE
corlin
corlin
corlin
Software Requirement : encapsulation,quality , and reuse /Rick Lutowski
Yu,Wang
corlin
corlin
None
corlin
Kasen
corlin 陈
- Rules should be written and made explicit.清晰书写，没有歧义
- Rules should be expressed in plain language.简明表达
- Rules should exist independent of procedures and workflows.依赖于过程和工作流
- Rules should build on facts, and facts should build on concepts as represented by terms.
规则基于现实／事实／论据，现实建立在术语表示的概念基础上。 - Rules should guide or influence behavior in desired ways.在期望路径内指导或影响行为
- Rules should be motivated by identifiable and important business factors.规则应由确定的重要商业因素推动
- Rules should be accessible to authorized parties.只有被授权的组织才可访问
- Rules should be single-sourced.单一来源
- Rules should be specified directly by those people who have relevant knowledge.规则应由领域专家直接制定
- Rules should be managed. 可管理
corlin 陈
微软94年开始总结的一个软件实施框架，结合迭代和瀑布模式，旋转上升过程中加入验证点，讲求日构建，高风险高优先级，扁平组织管理，人员合理分工。和敏捷方法有很多共同点，又不失规范和可跟踪。。
以前很少关注微软的方法学，失误阿。）
资源：
Microsoft 解决方案框架版本 3.0 概述
http://www.microsoft.com/china/technet/itsolutions/techguide/msf/msfovrvw.mspx
Microsoft 解决方案框架
http://www.microsoft.com/china/technet/itsolutions/techguide/msf/default.mspx
下载中的资源很不错。
参考书目：
对应MSCD的开始编目是MCSD.NET Exam 70-300
《Analyzing Requirements and Defining Microsoft .NET Solution Architectures》
http://www.microsoft.com/mspress/china/books/book20239.htm
中译本为：
《MCSD制胜宝典：需求分析与Microsoft.NET解决方案体系结构定义》
http://www.welan.com/199909/
corlin 陈
corlin 陈
软件需求的分支与约束
需求工程(Requirements Engineering)包括:
需求获取 是需求分析员与系统的最终用户一起工作以明确用户需要的过程，
需求分析 是提炼用户的需要和约束的过程，
需求规约 是清楚、准确地编写用户需要和约束文档的过程，
需求验证
是保证系统需求完整、正确、一致、明白的过程，
需求管理 是调度、协调需求工程活动，如获取、分析、规约及验证，并编制文档的整体过程。
在实际工作中，伴随着需求的改进，需求工程的各阶段有时是交织在一起的，
其最终结果是产生需求分析文档《软件需求规格说明书》(Software Requirement Specifications SRS)
相当于最终用户和开发机构之间的技术合同书。
需求包括
业务需求（Business Requirement）反映丁组织机构或客户对系统、产品高层次的目标要求
用户需求（User Requirement）描述了用户使用产品必须完成的任务
功能需求（Functional Requirement）定义丁开发人员必须实现的软件功能。
对需求的约束
完整性:要从全局出发，不能单纯从本业务考虑问题。一方面要完整地反映该项业务，另一方面还要全面反映本项业务同其它关联业务的联系。
准确性:准确无误，无二义，各项要求、业务做法、每种处理的详细流程、数据等方面的要求等明确定义，不能摸棱两可、含糊不清。
通用性:业务需求要具有较广泛的适应性，要能够适应大部分分支机构、适应大部分业务处理情况，减少以后各分支机构对系统的修改要求。
前瞻性:业务需求要具有前瞻性，要能够反映该项业务当前的发展状况(包括同业情况)和发展趋势。系统要留有可扩充的余地。
稳定性:一定时限内相对稳定、不变。
权威性:业务需求要具有权威性，能被普遍接受，并具有很强的约束力。
可行性:需求在技术实现和经济负担上要符合实际，切实可行。
安全性:从需求的提出就应充分考虑软件的安全性问题，要有专门负责安全生产或稽核的人员全程参与需求管理及软件开发。
Computer Supported Cooperative Work (CSCW) 计算机支持的协同工作应该能很好的协助
1994年麻省理工学院的Iren Gieif提出，前景不错,感觉成本有些高,
corlin 陈
corlin 陈
* Responsibility
o Analysis requirements to stories
o Help clients on their requirements
+ give them suggestions not dreams
+
find out new requirements
o Assist PM on iteration management
o Coach clients prioritizing stories
+ everything has cost (time, people, quality).
+ clients should balance which story has most important
business value.
+ High risks,
o Answer requirements relative questions for developers
o Guarantee acceptance tests
o know everyone in the office and keep a eye on what they are
doing
* Communication
o Clients-side
o a high level vision
rather than implementation description
o remember to ask why they need this story
o talk to developers to know potential problems and analysis
o if we use another way implemented the story target, is it
acceptable?
o different way have different cost, simplicity first
* Iterations Management
o stories
+
we don't always choose stories based purely on this
prioritizing, other factors often come in to play
go through all stories with customer after iteration
or phase finished
stories should be detailed enough to implement and test
high level estimate by a group of developers
stories should reduce the dependences
o iterations
+
it makes more sense for us to focus on some smaller
low-value stories (so that we can build development
momentum, and show everyone the process that we are
using) than it does to take the bigger, more complex
(and yet more valuable) stories. As we move into
iteration two, we will begin to focus more on the
higher value stories, whilst also making sure that the
development order makes sense from a technical
perspective.
go through all stories at IPM, find more problems,
questions
* Business
o BA should be more business
o BA should keep a high level vision of whole system
* User Interaction Design
o determine user experience or performance
corlin 陈
Why User Stories？
User stories emphasize verbal rather than written communication.强调口头沟通
User stories are comprehensible by both you and the developers.地球人都知道(BA,Dev,User)
User stories are the right size for planning.适合计划
User stories work for iterative development.为迭代开发
User stories encourage deferring detail until you have the best understanding you are going to have about what you really need.
激励你明确所需后才进行需求细化
User stories support opportunistic design.避免投机取巧,偷工减料
User stories encourage participatory design.鼓励分享设计
User stories build up tacit knowledge 构建隐性知识
| User Stories Applied: For Agile Software Development （Chapter 13. Why User Stories?） | ||
| By Mike Cohn | ||
| Publisher | : Addison Wesley | |
| Pub Date | : March 01, 2004 | |
| ISBN | : 0-321-20568-5 | |
| Pages | : 304 | |
txy
Zhang Ke
|
各位，小弟潜水很长时间了，今天冒个泡，请教几个问题。
1. AJAX用XMLHttpRequest的时候是不是不能将request指向当前web application域之外的service?比如请求的URL是http://www.google.com
2. forward在server端可以向其它的域内的service请求资源，而且不需要client的browser参与？
3. sendRedirect向client端发出特殊的HTTP指令，由browser向相应的service请求资源？
4, 但是上述两种方法是否都不能完成类似proxy的功能？比如我向自己的servlet提交一个URL(http://www.google.com)，我能用上面的方法拿到google首页的HTML代码么？（并不是要客户端转向，而是通过AJAX发请求，拿到HTML代码）
5. 我是否应该用java.net.URL直接在servlet端访问google来实现这个功能呢？
可能我问得不太清楚，试着讨论一下吧，谢谢啦。
Antix | |||
|
|
哈哈
shanzb
----------------------------------