Unit 2.1 and 2.2
Unit 2.1 and 2.2
2) Keep it simple
• All design and implementation should be as simple as possible
Planning Estimating
Scheduling Tracking
Modelling
Analysis Design
Construction
Code Test
Deployment
Delivery
Support
Feedback
1) Listen to the speaker and concentrate on what is being said
2) Prepare before you meet by researching and
understanding the problem
3) Someone should facility the meeting and have an agenda
4) Face-to-face communication is best, but also have a
document or presentation to focus the discussion
5) Take notes and document decisions
6) Strive for collaboration and consensus
7) Stay focused on a topic; modularize your discussion
8) If something is unclear, draw a picture
9) Move on to the next topic a) after you agree to something,
b) if you cannot agree to something, or c) if a feature or
function is unclear and cannot be clarified at the moment
10) Negotiation is not a contest or a game; it works best when
both parties win
14
1) Understand the scope of the project
2) Involve the customer in the planning activity
3) Recognize that planning is iterative; things will
change
4) Estimate based only on what you know
5) Consider risk as you define the plan
6) Be realistic on how much can be done each day
by each person and how well
7) Adjust granularity as you define the plan
8) Define how you intend to ensure quality
9) Describe how you intend to accommodate
change
10) Track the plan frequently and make adjustments
as required
15
1) Understand the problem you are trying to solve
2) Understand basic design principles and concepts
3) Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate
4) Select a programming environment that provides tools
that will make your work easier
5) Create a set of unit tests that will be applied once the
component you code is completed
1) Constrain your algorithms by following structured
programming practices
2) Select data structures that will meet the needs of the
design
3) Understand the software architecture and create
interfaces that are consistent with it
4) Keep conditional logic as simple as possible
5) Create nested loops in a way that makes them easily
testable
6) Select meaningful variable names and follow other
local coding standards
7) Write code that is self-documenting
8) Create a visual layout (e.g., indentation and blank lines)
that aids code understanding
1) Conduct a code walkthrough
2) Perform unit tests (black-box and white-box) and
correct errors you have uncovered
3) Refactor the code
1) All tests should be traceable to the software
requirements
2) Tests should be planned long before testing begins
3) The Pareto principle applies to software testing
• 80% of the uncovered errors are in 20% of the code
4) Testing should begin “in the small” and progress toward
testing “in the large”
• Unit testing --> integration testing --> validation
testing --> system testing
5) Exhaustive testing is not possible
1) Customer expectations for the software must be
managed
• Be careful not to promise too much or to mislead the
user
2) A complete delivery package should be assembled and
tested
3) A support regime must be established before the
software is delivered
4) Appropriate instructional materials must be provided to
end users
5) Buggy software should be fixed first, delivered later