Software Engineering Shari Lawrence Pfleeger Software Engineering General

Software Engineering • Shari Lawrence Pfleeger – Software Engineering • General text Spring 2017 (c) Ian Davis 1

Design Issues • Frederick Brooks – The design of design • www. cs. unc. edu/~brooks/Designof. Design – Supporting material Spring 2017 (c) Ian Davis 2

Understanding people/projects • Fred Brooks – The Mythical Man Month • Edward Yourdon – Death march Spring 2017 (c) Ian Davis 3

Software Architectures • Ian Gorton – Essential Software Architecture • Richard Taylor – Software Architecture Spring 2017 (c) Ian Davis 4

Design Patterns • Gamma et. Al (Gang of four) – Design Patterns • Head First Design Patterns – Eric & Elizabeth Freeman Spring 2017 (c) Ian Davis 5

Quantum Computing Spring 2017 (c) Ian Davis 6

Doing the math • Denning & Buzen – The operational analysis of queuing network models – ACM Computer Surveys 10. 3 September 1978 Spring 2017 (c) Ian Davis 7

Development Processes • Sanjeev Sharma and Bernie Coyne. Dev. Ops for Dummies. Spring 2017 (c) Ian Davis 8

Software Architecture • • Not about doing things a certain way It is about seeing the way things should be done It isn’t what I can teach or you can learn It is about being creative and thinking outside of the existing boxes. • It is about an evolving technology • It is knowing how to address unknowns Spring 2017 (c) Ian Davis 9

The design process • Requirements – What has to be accomplished • Architecture – Vision as to how the requirements can best be realised – The framework for how best to implement • Detailed Design – Getting each piece of the puzzle the right shape – Fitting it with the other pieces Spring 2017 (c) Ian Davis 10

Requirement. v. Design • Requirements first – Decide what you want before you design – Reduce risks – But some people can’t think abstractly • Architecture and design – Risky if you don’t have a clear idea of objective – But may help clarify objectives – Plan to throw one away (you will anyway) – Trading earlier start against perhaps more work Spring 2017 (c) Ian Davis 11

Taking the CS 446 challenge • Software engineering is common sense – 98% good practices, 2% impossible – 5% success, 95% failure (In 1980’s) – 25% of teams don’t deliver (Recent IBM survey) – Common sense is not very common • Hard to teach – Common sense comes across as incredibly boring – No right answers, but many wrong ones – Software is as much art as it is science Spring 2017 (c) Ian Davis 12

http: //www. businessweek. com/printer/articles/256666 avoiding-the-inventor-s-lament? type=old_article Spring 2017 (c) Ian Davis 13

Åstebro, Thomas, “The Return to Independent Invention: Evidence of Unrealistic Optimism”, The Economic Journal 113 (484), 226 -239, January, 2003. Spring 2017 (c) Ian Davis 14

Spring 2017 (c) Ian Davis 15

Is software development an art? • YES – Getting it right the first time demands vision. – There is beauty in a good design. – It is easy to appreciate a good design and dislike a bad one, at a raw gut level. • NO – Little argument about what is good or bad Spring 2017 (c) Ian Davis 16

Measuring good and bad • Transcendental view – Something we can recognise but not define • User view – Fit for purpose • Manufacturing view – Conformance to specification • Product view – How well is it internally put together • Marketing view $$$ Spring 2017 (c) Ian Davis 17

What are your personal goals • • Speed of development Correctness of solution Ease of comprehension Elegance of design Providing leadership Being a great team player Writing code no one else can understand Getting out of university alive Spring 2017 (c) Ian Davis 18

Because goals differ • No right way to program – But still some obviously wrong ways to program • Differing goals can produce: – Disagreement and conflict • Bad code is easier to correct than a disfunctional team – Focus on being a team player Spring 2017 (c) Ian Davis 19

What do you bring to your team • • Good architect (Have vision) Good Programmer (what languages) Genius - know API’s/database/research etc. Tester (Able to get problems on ground) – Able to say what is ugly or needs thought • Technical writer (Can produce readable docs) • Seller (Can sell an idea, present, justify) • Manager (Can organise, and reduce risk) Spring 2017 (c) Ian Davis 20

Goals of software development • • Need to understand requirements. Want software with maximum functionality. Code must be reliable. Cost to develop and maintain important. Want results as fast as possible. Must minimize development risks. Do no harm. Spring 2017 (c) Ian Davis 21

Problem • You cannot achieve all goals simultaneously! • Which of these goals are you willing to compromise on? • How do you identify which (if any) of these goals is realistic or realizable? Spring 2017 (c) Ian Davis 22

Software engineering to rescue • • Identify desired functionality Plan/cost activities Develop architectural design Monitor progress Document decision points Identify problems ASAP Test exhaustively Constantly collaborate with stake holders Spring 2017 (c) Ian Davis 23

Is software development engineering? • YES – We are building things. – Need a methodology to succeed. – Need engineering management skills. – Need to appreciate the importance of quality and reliability. – Need professional standards, discipline, and bodies. – Should be held accountable for our actions. Spring 2017 (c) Ian Davis 24

Is software development engineering? • NO – Not concerned with designing within tolerances – Code is either right or wrong (ie. Maths) – Limited/questionable concern with reuse of code – Not building ‘n’ of the same. Each project is new and unique. – Cookbook for algorithms, but not the project. Spring 2017 (c) Ian Davis 25

Acid tests • Which of the development goals are more achievable using engineering principals? • Can software development be a set of well defined manageable discrete logical steps? • When is a picture/design/essay worth 1000 lines of code? • When does theory encourage needless bureaucratic displacement activities? Spring 2017 (c) Ian Davis 26

The basic issues • Get it right the first time, that’s the main thing • Getting it right at the end doesn’t fly • So how do you avoid getting it wrong? • Plan to throw your first attempt away - you will anyway • If you plan to throw your first attempt away you will throw at least two attempts away Spring 2017 (c) Ian Davis 27

Software for profit • You can summon spirits from the deep • But will they come when you call? ? – Investment issues (Can you support the project) – Marketing issues (Can you sell the project) – Leading edge Technology (Bleeding edge) – Competitive Risks (Future knowns / unknowns) – Customer Adoption (Market feedback) – Corporate Persistence (Start when young) – Team Disillusionment (Lot of early punishment) – Swimming with sharks (Risk of being cheated) Spring 2017 (c) Ian Davis 28