CSE 331 Context Software Design and Implementation CSE331 is almost over… • Focus on software design, specification, testing, and implementation – Absolutely necessary stuff for any nontrivial project Lecture 22 • But not sufficient for the real world: At least 2 key missing pieces System Development – Techniques for larger systems and development teams • This lecture; yes fair game for final exam • Major focus of CSE403 – Usability: interfaces engineered for humans • Another lecture: didn’t fit this quarter • Major focus of CSE440 Zach Tatlock / Spring 2018 Outline Architecture • Software architecture Software architecture refers to the high-level structure of a software system – A principled approach to partitioning the modules and • Tools controlling dependencies and data flow among the modules – For build management – For version control Common architectures have well-known names and well-known – For bug tracking advantages/disadvantages • Scheduling A good architecture ensures: – Work can proceed in parallel • Implementation and testing order – Progress can be closely monitored – The parts combine to provide the desired functionality
Example architectures A good architecture allows: Pipe-and-filter (think: iterators) • Scaling to support large numbers of ______ Source pipe pipe pipe pipe • Adding and changing features Filter Filter Filter Sink • Integration of acquired components Blackboard Layered • Communication with other software (think: callbacks) (think: levels of abstraction) • Easy customization – Ideally with no programming Component Component – Turning users into programmers is good • Software to be embedded within a larger system Component Message store • Recovery from wrong decisions – About technology Component Component – About markets System architecture Temptations to avoid • Have one! • Avoid featuritis • Subject it to serious scrutiny – Costs under-estimated – At relatively high level of abstraction • Effects of scale discounted – Basically lays down communication protocols – Benefits over-estimated • Strive for simplicity • A Swiss Army knife is rarely the right tool – Flat is good • Avoid digressions – Know when to say no – Infrastructure – A good architecture rules things out – Premature tuning • Reusable components should be a design goal • Often addresses the wrong problem – Software is capital • Avoid quantum leaps – This will not happen by accident – Occasionally, great leaps forward – May compete with other goals the organization behind the – More often, into the abyss project has (but less so in the global view and long-term)
Outline Build tools • Building software requires many tools: • Software architecture – Java compiler, C/C++ compiler, GUI builder, Device driver build tool, InstallShield, Web server, Database, scripting • Tools language for build automation, parser generator, test – For build management generator, test harness – For version control • Reproducibility is essential • System may run on multiple devices – For bug tracking – Each has its own build tools • Everyone needs to have the same toolset! • Scheduling – Wrong or missing tool can drastically reduce productivity • Hard to switch tools in mid-project • Implementation and testing order If you’re doing work the computer could do for you, then you’re probably doing it wrong Version control (source code control) Bug tracking • A version control system lets you: • An issue tracking system supports: – Collect work (code, documents) from all team members – Tracking and fixing bugs – Synchronize team members to current source – Identifying problem areas and managing them – Have multiple teams make progress in parallel – Communicating among team members – Manage multiple versions, releases of the software – Tracking regressions and repeated bugs – Identify regressions more easily • Example tools: • Essential for any non-small or non-short project – Subversion (SVN), Mercurial (Hg), Git • Policies are even more important • Example tools: – When to check in, when to update, when to branch and Bugzilla, Flyspray, Trac, hosted tools (Sourceforge, Google merge, how builds are done Developers, GitLab/GitHub, Bitbucket, …) – Policies need to change to match the state of the project • Always diff before you commit
Bug tracking Outline Need to configure the bug tracking system to match the project • Software architecture – Many configurations can be too complex to be useful A good process is key to managing bugs • Tools – An explicit policy that everyone knows, follows, and believes in – For build management – For version control – For bug tracking Prioritize Assign Replicate Examine • Scheduling • Implementation and testing order Bug Close Verify Fix Discover found Scheduling Scheduling is crucial but underappreciated “More software projects have gone awry for lack of calendar time • Scheduling is underappreciated than for all other causes combined.” – Made to fit other constraints -- Fred Brooks, The Mythical Man-Month • A schedule is needed to make slippage visible – Must be objectively checkable by outsiders Three central questions of the software business • Unrealistically optimistic schedules are a disaster 3. When will it be done? – Decisions get made at the wrong time 2. How much will it cost? 1. When will it be done? – Decisions get made by the wrong people – Decisions get made for the wrong reasons • Estimates are almost always too optimistic • The great paradox of scheduling: • Estimates reflect what one wishes to be true – Hofstadter’s Law: It always takes longer than you expect, • We confuse effort with progress even when you take into account Hofstadter's Law • Progress is poorly monitored – But seriously: 2x longer, even if think it will take 2x longer • Slippage is not aggressively treated
Effort is not the same as progress How does a project get to be one year late? Cost is the product of workers and time One day at a time… – Reasonable approximation: All non-people costs (mostly • It’s not the hurricanes that get you salary) are zero (?!) • It’s the termites – Easy to track – Tom missed a meeting – Mary’s keyboard broke Progress is more complicated – The compiler wasn’t updated – Hard to track – … • People don’t like to admit lack of progress If you find yourself ahead of schedule – Think they can catch up before anyone notices – Don’t relax – Assume they (you) are wrong – Don’t add features • Design the process and architecture to facilitate tracking Controlling the schedule Milestones • First, you must have one • Milestones are critical keep the project on track • Avoid non-verifiable milestones – Policies may change at major milestones – 90% of coding done – Check-in rules, build process, etc. – 90% of debugging done – Design complete • Some typical milestones (names) • 100% events are verifiable milestones – Design complete – Module 100% coded – Interfaces complete / feature complete – Unit testing successfully complete – Code complete / code freeze • Need critical path chart (Gantt chart, PERT chart) – Alpha release – Know effects of slippage – Beta release – Know what to work on when – Release candidate (RC) – FCS (First Commercial Shipment) release
Dealing with slippage Outline • People must be held accountable • Software architecture – Slippage is not inevitable – Software should be on time, on budget, and on function • Tools – For build management • Four options – For version control – Add people – startup cost (“ mythical man-month ”) – For bug tracking – Buy components – hard in mid-stream – Change deliverables – customer must approve • Scheduling – Change schedule– customer must approve • Implementation and testing order • Take no small slips – One big adjustment is better than three small ones How to code and test your design Bottom-up A • You have a design and architecture • Implement/test children first – Need to code and test the system – For example: G, E, B, F, C, D, A B C D • First, test G stand-alone (also E) • Key question, what to do when? – Generate test data as discussed earlier E F – Construct drivers G • Suppose the system has this module dependency diagram • Next, implement/test B, F, C, D – In what order should • No longer unit testing: use lower-level modules you address the pieces? A – A test of module M tests: • whether M works, and • whether modules M calls behave as expected B C D – When a failure occurs, many possible sources of defect E F – Integration testing is hard, irrespective of order G
Recommend
More recommend
