1 / 28

Software Engineering

Software Engineering. Shari Lawrence Pfleeger Software Engineering General text. Design Issues. Frederick Brooks The design of design www.cs.unc.edu/~brooks/DesignofDesign Supporting material. Understanding people/projects. Fred Brooks The Mythical Man Month Edward Yourdon Death march.

backstrom
Télécharger la présentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

  6. Quantum Computing (c) Ian Davis

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

  8. Development Processes • Sanjeev Sharma and Bernie Coyne. DevOps for Dummies. (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 (c) Ian Davis

  10. 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 (c) Ian Davis

  11. 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 (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 (c) Ian Davis

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

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

  15. (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 (c) Ian Davis

  17. 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 $$$ (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 (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 (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) (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. (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? (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 (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. (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. (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? (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 (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) (c) Ian Davis

More Related