Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Transcript of ITECH3501/6501 W03
Jia Rong, email@example.com
What have we covered last week?
Requirements deficiencies are the prime source of project failures.
Law 1 -
(Robert Glass 1998)
Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.
(Kotonya and Sommerville, 2000)
Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed.
Law 2 -
Prototyping reduces requirements and design errors, especially for user interfaces.
Law 3 -
The value of the model depends on the view taken, but none is the best for all purpose.
Law 4 -
Objective models reduce communication problems between analysts and users.
Hypothesis 1 -
Today, we have a look at
good design process
system design is so
to design a system
Design generates a proposed technical solution, which meets the system requirement.
We simulate what we want to make or do
We iterate till the design is adequate
We prepare a technical plan, which tells other people how to construct the system
We write a design specification
System Design answers the questions:
Which functions will be implemented?
How will these functions be invoked by users?
How will the system be structured?
How should each function be implemented?
Take account of time, cost and performance constraints
A full design only for large or complex system
System Design is an artifact
limited by the ability and foresight of who makes it and the circumstances of its creation
design is the most challenging and most creative activity in software engineering
knowledge of the user requirements translates into knowledge about the computer system
good design is a good match
Properties & Process
What are good design? For what reason?
How to perform task?
End up as the design specification
Whether system functions and user community are clearly defined?
Has any conflicts among the developers or user groups?
Network and Hardware Structure
Storage and Retrieval
System Design Process
There is no single best design for all systems.
It is better to spend more time on design than to start coding.
The key problem in design is that it requires knowledge of both applications and computation.
Law 5 -
Good designs require deep application knowledge.
Law 6 -
Hierarchical structures reduce complexity.
Law 7 -
A structure is stable if cohesion is strong and coupling is low.
the vulnerability of the structure to the normal incidents of programming
modifications required by design or environment changes
Law 8 -
Only what is hidden can be changed without risk.
Law 9 -
Separation of concerns leads to standard architectures.
Law 10 -
Screen pointing time is a function of distance and width.
Hypothesis 2 -
Object-oriented designs reduce errors and encourage re-use.
Hypothesis 3 -
Formal methods significantly reduce design errors, or eliminate them early.
Hypothesis 4 -
Reusing designs through patterns yields faster and better maintenance.
Graphical User Interface
The golden rules of interface design:
strive for consistency
enable frequent users to use shortcuts
offer informative feedback
design dialogs to yield closure
offer error prevention and simple error handling
permit easy reversal of actions
support internal locus of control
reduce short-term memory load
The information hiding or encapsulation principle led to the development of abstract data types, the basis of object-oriented design.
Modules should be divided so that each is changeable without impact on others.
Each module should be concerned with only one thing at a time.
Use Cases and classes identified during requirements are directly translatable into design.
Make use of concepts like sets and relations to generate and document a design result in a higher degree of reliability as they remove ambiguity and imprecision
Experienced designers reuse successful elements of previous design
Programmer productivity and program quality are improved
Skills of novices are increased by reusing proven concepts
Communication among designers is easier
Encourages the exchange of good design idea
Maintainability of programs is improved
How can we evaluate the quality of the system design?
Depends on how well the design meets the requirements
Is the design easy to build the system?
An awful and useless product may be well designed, and vice verse
Detailed enough that the planning and cost estimating for the next phase can be done
Evaluate which information needed by whom, and when