1 / 16

Software Engineering

Explore major construction practices, from coding to teamwork, and key decisions influencing productivity. Learn about design challenges, tools, and the importance of experienced programmers.

jyokum
Download Presentation

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 Key construction decisions Design challenges

  2. Key construction decisions • Choice of programming paradigm, language and environment: • Can improve productivity, reliability, simplicity and comprehensibility by an order of magnitude • Strongly influenced by previous experience • Experienced programmers in a language can be up to 30% more productive than non-experienced ones • “Experience” can take as much as three years to get

  3. Key construction decisions • Architectural guidelines and programming conventions: • Many alternatives exist, coherence and discipline are important

  4. Key construction decisions • Location on the “technology wave”: • End of the wave: bug-free compilers and environments, several alternative tools, powerful environments, good documentation, integrated tools, availability of courses and experts. • Beginning of wave: buggy compilers and environments, few choices, primitive environments, poor documentation, lack of integration, inexperienced community – “pioneers in the wild”.

  5. Key construction decisions • Programmers should make good use of paradigm, language and environment, but... • Programmers should program into the language, and not in the language (see next slides):

  6. Key construction decisions • Programming in the language: language filters and determines patterns of reasoning about problem and its solutions Programmer Problem Language

  7. Key construction decisions • Programming into the language: programmer analyses problem based on their personal skills and techniques, and then makes good use of language to implement solution Programmer Language Problem

  8. Major construction practices • Major construction practices checklist: • Coding • How much design will be done before coding, and how much will be done “just in time”? • Are conventions defined for names, comments and layout?

  9. Major construction practices • Coding (cont): • Specific coding practices implied by architecture: • Handling of error conditions • Security issues • Conventions for class interfaces • Standards applicable to reused code • How much to consider performance while coding

  10. Major construction practices • Coding (cont): • Positioning on the technology wave • Programming in the language versus programming into the language • Teamwork: • Integration procedure – specific steps a programmer must go through before checking code into the master sources

  11. Major construction practices • Teamwork: • Pair programming, individual programming, or some other policy? • Quality assurance: • Will programmers write test cases for their code before writing the code itself? • Will programmers write unit tests for their code regardless of whether they write them first or last?

  12. Major construction practices • Quality assurance (cont): • Will programmers step through their code in the debugger before they check it in? • Will programmers integration-test their code before they check it in? • Will programmers review or inspect each other’s code?

  13. Major construction practices • Tools: • Have you selected a revision control tool? • Have you selected language, language version, and compiler version? • Have you selected a framework such as J2EE or Microsoft .NET or explicitly decided not to use a framework? • Have you decided whether to allow use of nonstandard language features? • Have you identified and acquired other tools you will be using – editor, refactoring tool, debugger, test framework, syntax checker, and so on?

  14. Design challenges • Design is a wicked problem • Wicked problem (H. Rittel and M. Webber, 1973): can only be clearly defined by being solved. Consequently, optimised solution can only be achieved by solving problem once, learning from experience, throwing solution away and solving problem again.

  15. Design challenges • Design is a sloppy process • When is design “good enough”? • How detailed should it be? • How formal? • How “just-in-time”? • When is it finished?

  16. Design challenges • Design is about tradeoffs and priorities under constraints • Design is nondeterministic • Design is heuristic • Design is emergent

More Related