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

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

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

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

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

6. Quantum Computing
Spring 2017
(c) Ian Davis

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

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

9. 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

10. The design process Requirements Architecture Detailed Design
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

11. Requirement .v. Design Requirements first Architecture and design
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

12. Taking the CS446 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

13. http://www. businessweek
Spring 2017
(c) Ian Davis

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

15. Spring 2017
(c) Ian Davis

16. 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

17. Measuring good and bad Transcendental view User 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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 the theory encourage needless bureaucratic displacement activities?
Spring 2017
(c) Ian Davis

27. 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

28. 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