FTC ACCA tips for June 2007 exam 2.1详解之designing冲刺版

zhongya8558 · 发表于 2007-5-21 19:55:37

看不到图的下这个，后面有附件
 
 
Designing 1 Methodologies
【how formal methodologies impose more discipline on the process of developing IS】<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com<img src=" /><o:p></o:p>
A formal systems development methodology can impose more discipline on the process of developing information systems in at least two ways.
Firstly, a systems development methodology usually has prescribed stages that the systems development has to pass through. For example, it may have a stage where the feasibility of the project is subjected to a cost-benefit analysis within a formal business case. This ensures that the project follows a defined lifecycle of best practice, which helps control the progress and conduct of the project.
Secondly, a systems development methodology usually has defined formal methods within each stage, which assist the successful definition and conduct of the project. For example, the feasibility stage may have a defined cost-benefit analysis (say Time to Payback) which contains the method and the criteria for successful completion (for example, projects pay back within three years). Furthermore, a formal methodology will include explicit quality control mechanisms.
【waterfall approach】<o:p></o:p>
①Sequential stages e.g. Feasibility study, systems analysis, systems design, programming, testing and implementation. 
②Must complete a stage before moving to next one.
③Outputs of one stage are inputs of next one. e.g. systems specification output of systems analysis and input into systems design. 
④Each stage is divided into two parts. The first part concerns the actual work required in the stage. The second part concerns the validation and verification of that work. There is usually iteration of work and products within each stage but very little between each stage.
【spiral approach】<o:p></o:p>
The spiral approach introduces a more evolutionary or iterative approach to systems development. At the beginning of a project, requirements may be poorly understood and an initial prototype may be constructed to help determine these requirements. This situation is represented at the centre of the spiral approach. As the requirements become clearer, successive prototypes are developed to refine this understanding and the software increasingly mirrors the requirements of the user. The spiral approach sweeps out from the centre with four quadrants representing different development issues.
－The top left quadrant is where objectives are determined and alternatives and constraints identified
－The top right quadrant is where alternatives are evaluated and the various risks are identified and resolved
－The bottom right is where development actually takes place
－The bottom left is where the next phase of the iteration is planned
The work in each of these quadrants is performed at each rotation of the spiral. Hence actual development (roughly analogous to the more conventional waterfall approach) actually takes place as often as the spiral rotates.
【two advantages of the waterfall approach】<o:p></o:p>
Easier quality assurance<o:p></o:p>
The products that mark the end of each stage can be rigorously quality assured before the development passes on to the next stage. For example, the systems specification may have to conform to certain diagramming standards, consist of a number of agreed products and be subject to detailed review and formal sign-off before it can progress to design and development. Errors and omissions in the specification may be discovered early in development, where it is cheap to fix them and subsequent design is based upon a fixed defined requirement, rather than ambiguously defined moving goalposts.
Easier project planning and control<o:p></o:p>
Most waterfall approaches (such as SSADM) not only have products defining the end of each stage but detailed products that have to be produced within each stage. This product breakdown structure is ideal for project planning, as it essentially provides a low-level breakdown of the project, together with dependencies between those low-level products. This forms the basis of the project plan for each stage.
Designing 2 Modeling<o:p></o:p>
◆flowchart & DFD            04D5 04J1 02D6<o:p></o:p>
A Data Flow Diagram (DFD) is a possible process model. An example is shown below:<o:p></o:p>
<IMG height=260 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image002.jpg" width=442 v:shapes="_x0000_i1027"><o:p></o:p>
External entity is a source or destination of data which is considered external to the system. Duplicated entities have a diagonal line at the top left of the ellipse. The external entity may be show as below.<o:p></o:p>
<IMG height=50 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image004.jpg" width=125 v:shapes="_x0000_i1025"><o:p></o:p>
Data Store  Stored data of any kind (digital or paper). The data store may be shown as below.<o:p></o:p>
<IMG height=49 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image006.jpg" width=372 v:shapes="_x0000_i1028"><o:p></o:p>
Process involves data being used or altered. The process should be described with a terse verb + object statement. The process may be shown as below.<o:p></o:p>

<TABLE cellSpacing=0 cellPadding=0>
<TBODY>
<TR>
<TD style="BORDER-RIGHT: #ece9d8; BORDER-TOP: #ece9d8; VERTICAL-ALIGN: top; BORDER-LEFT: #ece9d8; BORDER-BOTTOM: #ece9d8; BACKGROUND-COLOR: transparent" width=76 height=35>
<TABLE cellSpacing=0 cellPadding=0 width="100%">
<TBODY>
<TR>
<TD style="BORDER-RIGHT: #ece9d8; BORDER-TOP: #ece9d8; BORDER-LEFT: #ece9d8; BORDER-BOTTOM: #ece9d8; BACKGROUND-COLOR: transparent">
<DIV class=shape style="PADDING-RIGHT: 7.2pt; PADDING-LEFT: 7.2pt; PADDING-BOTTOM: 3.6pt; PADDING-TOP: 3.6pt" v:shape="_x0000_s1026">
/role</DIV></TD></TR></TBODY></TABLE> </TD></TR></TBODY></TABLE><IMG height=90 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image008.jpg" width=350 v:shapes="_x0000_i1029"><o:p></o:p>
A data flow represents the movement of data from one point in the system to another. A flow pointing into a data store represents some form of update. A flow pointing away from a data store represents a read only operation. The data flow may be shown as below. <IMG height=49 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image010.jpg" width=457 v:shapes="_x0000_i1030"><o:p></o:p>
◆ERM  05j5 <o:p></o:p>
The entity-relationship model is a typical diagram for modelling static structures.<o:p></o:p>
<IMG height=213 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image012.jpg" width=396 v:shapes="_x0000_i1031"><o:p></o:p>
An entity is a thing the organisation wishes to hold information about. The entity is represented as a singular noun in a rectangle.<o:p></o:p>
 <IMG height=24 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image014.jpg" width=110 v:shapes="_x0000_i1032"><o:p></o:p>
Relationships describe business connections between two entities and are represented by lines between the entities. An ERM may show three main types of relationship: 1:1, 1:M, M:M.<o:p></o:p>
<IMG height=94 src="file:///C:/DOCUME~1/king/LOCALS~1/Temp/msohtml1/01/clip_image016.jpg" width=342 v:shapes="_x0000_i1026"><o:p></o:p>
◆ELH  <o:p></o:p>
Entity:customer account<o:p></o:p>
Create
Amend:update<o:p></o:p>
Delete:close<o:p></o:p>
Note:   Sequence-<o:p></o:p>
       Iteration-<o:p></o:p>
       Selection-<o:p></o:p>
◆Graphical model for defining user requirements(help control requirements creep)   02J2<o:p></o:p>
-Within each stage of the SDLC there will be models for defining user requirements.<o:p></o:p>
-Many of these models, such as DFD and flowcharts are constructed to a standard notation. -They are more precise than the informal narrative methods.<o:p></o:p>
-The construction of the models usually means key business rules have been understood.<o:p></o:p>
-Such models can be quality assured effectively.<o:p></o:p>
Designing 3 Invitation to tender<o:p></o:p>
【four constituent sections of ITT】<o:p></o:p>
Information about the tender itself <o:p></o:p>
when & how to return the tender, contact person for query
Functional requirements<o:p></o:p>
These are the business functions the org wants the software package to support. These may be provided as a textual list or diagrammatic models. The business requirements are often prioritised so that the supplier can determine whether their product supports the most important requirements.
Non-functional requirements<o:p></o:p>
There may also be a list of non-functional requirements such as security, audit, backup and recovery requirements. This section may specify the type of user interface as well as the interfaces required to other systems in the org. <o:p></o:p>
Supplier information<o:p></o:p>
name and registered address of the vendor
telephone number, fax number and e-mail address
Contact name for this tender (extension number, direct line)
Designing 4 Quality software characteristics<o:p></o:p>
【why sw can not be fault free】难于预料+预测耗时<o:p></o:p>
①     impossible to predict how every user will use the sw →user may take action not imagined cause to fail.
②     difficult to predict how sw will interact with other sw →a screensaver may cause previous working sw to fail
③     time consuming to test all paths →some paths are inevitably are untested before released and so lead to fail
【Characteristics of a quality software (and measures)】 功能正确\容易使用\可靠<o:p></o:p>
Functional correctness of the sw（meet the user’s requirement）<o:p></o:p>
Poor specification of user req may lead to system do not work as they are supposed to <o:p></o:p>
Measure (a) express the percentage of business functions successfully available to the user<o:p></o:p>
Measure (b) track the number of requests for system changes in the months following system implementation<o:p></o:p>
Usability (easy to use)<o:p></o:p>
the software must be easy to use for the user. Usability problems may caused by confusing feature names or a confusing interface, or poor training of user<o:p></o:p>
Measure (a) logging the number of calls to the Help desk cause by the user being unable to use or misusing the system<o:p></o:p>
Measure (b) trained observer watching the user using the sw<o:p></o:p>
Reliability of the sw (no major bugs)<o:p></o:p>
The software should avoid regularly crashes. <o:p></o:p>
Measure (a) track the downtime eg. 99% of the time in a working day<o:p></o:p>
Measure (b) the number of faults reported
Designing 5 Decision table<o:p></o:p>
◆show the effect of a process, decision or action. They are often used in the context of system testing (P229)<o:p></o:p>
◆Explain how such a table would assist the testing of the software that will support this process.             <o:p></o:p>
-define all the possible cases (combination)<SPAN style="BORDER-RIGHT: windowtext 1pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: windowtext 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: windowtext 1pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: windowtext 1pt solid; mso-border-alt: solid windowtext .5pt"> <SPAN lang=EN-GB style="BORDER-RIGHT: windowtext 1pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: windowtext 1pt solid; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: windowtext 1pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: windowtext 1pt solid; mso-ansi-language: EN-GB; mso-border-alt: solid windowtext .5pt">04D6<o:p></o:p>
-predict the outcomes in advance of testing<o:p></o:p>
-each of the cases will be executed in testing and the actual outcomes compared with the predicted ones.<o:p></o:p>
Designing 6 Testing<o:p></o:p>
【自动测试工具】<o:p></o:p>
① It’s time consuming to manually create large stored data volumes, and it is difficult to manually simulate the concurrent user.
②automated tools can simulate concurrent user and diagnoses where bottlenecks are.
【预测在测试中的重要性】<o:p></o:p>
①define all possible cases→predict outcome→perform & compare
②It’s important to predict value in advance because
(a)    It formalizes and documents the testing
(b)    It is likely that erroneous outcomes are dealt with
【usability testing】
Usability testing: test whether the system is easy for user to learn & use
Role: system may be difficult to understand and difficult for the users to cope with because technical specialist’s familiarity with computers not possessed by many users. The usability testing can help ensure the usability of the software.
Conduct: firstly, the analysts who specified the system will perform testing to ensure that the system is easy to use. Secondly, end-users will comment during user-acceptance testing
【user acceptance testing】
①determine whether meets user requirements 
②take place after system testing has been completed
③user test the system by passing through realistic value and seeing if they produced the expected results 
④three types of error trend to emerge:
(a)failure to meet the defined business requirements
(b)usability problems may emerge that have to be addressed by restructuring the user interface 
(c) compatible and performance problems may emerge as the system is used
【system testing】
①System testing performed by analysts and attempts to find error in:
Business functionality－ensure the sw meets the function requirements 
Stability & reliability－the system should cope with unusual path and incorrect data
Usability－tester comment on the general usability as well as adherence to standards
②system testing may include integration testing and performance testing
Integration testing ensure the system interface correctly with other system 
Performance testing explore the limits of its performance
【unit testing】
①checks whether each program module meets the program specification 
②programmer perform unit testing
③unit testing combines both static and dynamic testing 
(a)static testing check program code
(b)dynamic testing ensure the program handle input/output correctly and each path has been executed correctly
【static & dynamic testing】
Static testing is usually associated with walkthroughs, peer reviews and the quality assurance activities that take place on the left-hand side of the V model. An example of a static test is the inspection of a functional specification to test whether it accurately reflects the user°Os requirements and adheres to internal or published standards. Static tests are also undertaken by the programmer. Code inspections are still claimed to be the most effective way of finding coding errors. 
Dynamic testing takes place on the software itself. In the example above, a tester entering values into the software and observing and recording the actual result will be undertaking dynamic testing. Dynamic testing takes place on the right- hand side of the V model, from unit testing through to user acceptance testing. It describes tests applied to executing software.
【regression testing】
Difinition: concerns testing ‘unchanged’ parts of the system to ensure a change has not caused a fault. <o:p></o:p>
Couse: A ‘simple’ change in one area of the system may have unpredicted effects elsewhere. It is therefore important to carry out regression testing.<o:p></o:p>
Implication for change process: affect the time and costs required for change process.<o:p></o:p>

[ 本帖最后由 zhongya8558 于 2007-6-1 20:28 编辑 ]

水瓶宝宝 · 发表于 2007-5-21 21:19:07

谢谢楼主，现在最需要的就是这个。

cohen · 发表于 2007-5-21 21:25:35

未经本站明确授权任何人不得引用或转载, 即便保留完整版权信息依然不允许

lixu361 · 发表于 2007-5-21 21:52:19

3KSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

qqwest · 发表于 2007-5-21 22:10:21

多谢了，ooooooo

chengcaesar · 发表于 2007-5-21 22:21:46

kankankankankanaknakn

chengcaesar · 发表于 2007-5-21 22:22:20

kankankankankanaknakn

miranda1120 · 发表于 2007-5-21 22:31:03

kkkkkkkkkkkkkkkkkkkkkkk

zhongya8558 · 发表于 2007-5-21 22:32:57

取消隐藏了，大家随意看，有缘的回个贴，免的沉下去

wclcnooc · 发表于 2007-5-22 09:50:42

thanks for sharing

账号		自动登录	找回密码
密码			立即注册

FTC ACCA tips for June 2007 exam 2.1详解之designing冲刺版

本帖子中包含更多资源

评分

未经本站明确授权任何人不得引用或转载, 即便保留完整版权信息依然不允许

回复 #1 zhongya8558 的帖子

thanks

好人卡