Some Notes from McConnell Code Complete 2

1
Some Notes from McConnellCode Complete 2

• CS436
• (material for quiz)

2
Software Construction

• Problem definition
• Requirements development
• Construction planning
• Sofware architecture/high-level design
• Detailed design
• Coding/debugging

3
Software Construction
Where are you on C? D? I? Did you do these
for B?

• Problem definition
• Requirements development
• Construction planning
• Sofware architecture/high-level design
• Detailed design
• Coding/debugging
• Unit testing
• Integration testing
• Integration
• System testing
• Corrective maintenance

4
In More Detail

• Verifying that the groundwork has been laid so
  that construction can proceed successfully
• Determining how your code will be used
• Designing and writing classes and routines
• Creating and naming variables and named constants
• Selecting control structures and organizing
  blocks of statements

5
In More Detail

• Unit testing, integration testing, and debugging
  your own code
• Reviewing other team members' low-level designs
  and code and having them review yours
• Polishing code by carefully formatting and
  commenting it
• Integrating software components that were created
  separately
• Tuning code to make if faster and use fewer
  resources

6
Metaphors

• Software penmanship
• Software farming
• Software accretion/evolution
• Software construction (according to plans)
• Graham hackers as painters
• Loui skill acquisition is a performance
  activity skill application is a creative activity

7
Classic Ideas

• Finding a problem downstream is much more
  expensive than finding it upstream(all sorts of
  cost figures are quoted)
• Maintenance/GUI/Adaptation/Re-release is more
  difficult/time-consuming programming than initial
  construction (all sorts of percentages are given)

8
Choose Sequential When

• The requirements are fairly stable
• The design is straightforward and fairly well
  understood
• The development team is familiar with the
  applications area
• The project contains little risk
• Long-term predictability is important
• The cost of changing requirements, design, and
  code downstream is likely to be high

9
Choose Iterative When

• The requirements are not well understood or you
  expect them to be unstable for other reasons
• The design is complex, challenging or both
• The development team is unfamiliar with the
  applications area
• The project contains a lot of risk
• Long-term predictability is not important
• The cost of changing requirements, design, and
  code downstream is likely to be low

10
Problem Definition

• Product vision / vision statement / mission
  statement / product definition
• Defines what the problem is without any reference
  to possible solutions
• Should be in user language
• Should be described from a user's point of view
• Loui be on the lookout for hidden objectives

11
Architectural Components

• Program organization major classes, data
  design/formats
• Business rules/requirements, User-Interface
  Design
• Resource Management (cpu, memory, ipc, network,
  database connections, power)
• Security
• Performance (different from 3)

12
Architectural Components

• Program organization major classes, data
  design/formats
• Business rules/requirements, User-Interface
  Design
• Resource Management (cpu, memory, ipc, network,
  database connections, power)
• Security
• Performance (different from 3)
• Scalability and interoperability
• Migration / internationalization / portability
• Error processing / fault tolerance
• Feasibility / overengineering
• Buy-vs-build components / reuse / change
• quality