Govindrao Wanjari College of Engineering & Technology,Nagpur Department of CSE Session: 2017-18

1. Govindrao Wanjari College of Engineering & Technology,NagpurDepartment of CSE Session: 2017-18 Branch/ Sem: CSE/6th sem “SOFTWARE ENGINEERING PRACTICES” Subject :SEPM Subject Teacher: Prof.P.Y.JANE

2. Outline • Principles form the basis of methods, techniques, methodologies and tools • Seven important principles that may be used in all phases of software development • Modularity is the cornerstone principle supporting software design • Case studies

3. Application of principles • Principles apply to process and product • Principles become practice through methods and techniques • often methods and techniques are packaged in a methodology • methodologies can be enforced by tools

4. A visual representation

5. Key principles • Rigor and formality • Separation of concerns • Modularity • Abstraction • Anticipation of change • Generality • Incrementality

6. Rigor and formality • Software engineering is a creative design activity, BUT • It must be practiced systematically • Rigor is a necessary complement to creativity that increases our confidence in our developments • Formality is rigor at the highest degree • software process driven and evaluated by mathematical laws

7. Examples: product • Mathematical (formal) analysis of program correctness • Systematic (rigorous) test data derivation

8. Example: process • Rigorous documentation of development steps helps project management and assessment of timeliness

9. Separation of concerns • To dominate complexity, separate the issues to concentrate on one at a time • "Divide & conquer" (divide et impera) • Supports parallelization of efforts and separation of responsibilities

10. Example: process • Go through phases one after the other (as in waterfall) • Does separation of concerns by separating activities with respect to time

11. Example: product • Keep product requirements separate • functionality • performance • user interface and usability

12. Modularity • A complex system may be divided into simpler pieces called modules • A system that is composed of modules is called modular • Supports application of separation of concerns • when dealing with a module we can ignore details of other modules

13. Cohesion and coupling • Each module should be highly cohesive • module understandable as a meaningful unit • Components of a module are closely related to one another • Modules should exhibit low coupling • modules have low interactions with others • understandable separately

14. A visual representation high coupling low coupling

15. Abstraction • Identify the important aspects of a phenomenon and ignore its details • Special case of separation of concerns • The type of abstraction to apply depends on purpose • Example : the user interface of a watch (its buttons) abstracts from the watch's internals for the purpose of setting time; other abstractions needed to support repair

16. Abstraction ignores details • Example: equations describing complex circuit (e.g., amplifier) allows designer to reason about signal amplification • Equations may approximate description, ignoring details that yield negligible effects (e.g., connectors assumed to be ideal)

17. Abstraction yields models • For example, when requirements are analyzed we produce a model of the proposed application • The model can be a formal or semiformal description • It is then possible to reason about the system by reasoning about the model

18. An example • Programming language semantics described through an abstract machine that ignores details of the real machines used for implementation • abstraction ignores details such as precision of number representation or addressing mechanisms

19. Abstraction in process • When we do cost estimation we only take some key factors into account • We apply similarity with previous systems, ignoring detail differences

20. Anticipation of change • Ability to support software evolution requires anticipating potential future changes • It is the basis for software evolvability • Example: set up a configuration management environment for the project (as we will discuss)

21. Generality • While solving a problem, try to discover if it is an instance of a more general problem whose solution can be reused in other cases • Carefully balance generality against performance and cost • Sometimes a general problem is easier to solve than a special case

22. Incrementality • Process proceeds in a stepwise fashion (increments) • Examples (process) • deliver subsets of a system early to get early feedback from expected users, then add new features incrementally • deal first with functionality, then turn to performance • deliver a first prototype and then incrementally add effort to turn prototype into product

23. Case study: compiler • Compiler construction is an area where systematic (formal) design methods have been developed • e.g., BNF for formal description of language syntax

24. Separation of concerns example • When designing optimal register allocation algorithms (runtimeefficiency) no need to worry about runtime diagnostic messages (user friendliness)

25. Modularity • Compilation process decomposed into phases • Lexical analysis • Syntax analysis (parsing) • Code generation • Phases can be associated with modules

26. Representation of modular structure boxes represent modules directed lines represent interfaces

27. Module decomposition may be iterated further modularization of code-generation module

28. Abstraction • Applied in many cases • abstract syntax to neglect syntactic details such as begin…end vs. {…} to bracket statement sequences • intermediate machine code (e.g., Java Bytecode) for code portability

29. Anticipation of change • Consider possible changes of • source language (due to standardization committees) • target processor • I/O devices

30. Generality • Parameterize with respect to target machine (by defining intermediate code) • Develop compiler generating tools (compiler compilers) instead of just one compiler

31. Incrementality • Incremental development • deliver first a kernel version for a subset of the source language, then increasingly larger subsets • deliver compiler with little or no diagnostics/optimizations, then add diagnostics/optimizations

32. Case study (system engineering): elevator system • In many cases, the "software engineering" phase starts after understanding and analyzing the "systems engineering” issues • The elevator case study illustrates the point

33. Rigor&formality (1) • Quite relevant: it is a safety critical system • Define requirements • must be able to carry up to 400 Kg. (safety alarm and no operation if overloaded) • emergency brakes must be able to stop elevator within 1 m. and 2 sec. in case of cable failures • Later, verify their fulfillment

34. Separation of concerns • Try to separate • safety • performance • usability (e.g, button illumination) • cost • although some are strongly related • cost reduction by using cheap material can make solution unsafe

35. A modular structure Control apparatus buttons at floor i B3 Elevator B2 B1

36. Module decomposition may be iterated

37. Abstraction • The modular view we provided does not specify the behavior of the mechanical and electrical components • they are abstracted away

38. Anticipation of change, generality • Make the project parametric wrt the number of elevators (and floor buttons)

39. Govindrao Wanjari College of Engineering & Technology,NagpurDepartment of CSE Session: 2017-18 Branch/ Sem: CSE/6th sem “SOFTWARE TESTING” Subject :SEPM Subject Teacher: Prof.P.Y.JANE

40. Overview • Definition of Software Testing • Problems with Testing • Benefits of Testing • Effective Methods for Testing

41. Definition of Software Testing Software testing is the process of executing a software system to determine whether it matches its specification and executes in its intended environment.

42. “Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence” [Dijkstra, 1972]

43. Why Test? Q: If all software is released to customers with faults, why should we spend so much time, effort, and money on testing?

44. Cost of Delaying the Release of a Software Product • Timing is another important factor to consider. • New products: The first to the market often sells better than superior products that are released later.

45. Beta Testing • Customers test for free! • Seems to give you test cases representative of customer use. • Helps to determine what is most important to the customers. • Can do more configuration (environment) testing than in your testing lab.

46. Problems with Beta Testing • Most beta testers are “techies” who have a higher tolerance of bugs. They do not represent the average customer. • Beta testers usually won’t report: usability problems, bugs they don’t understand and bugs that seem obvious. • Takes much more time and effort to handle a user reported bug.

47. Cutting Testing Costs can Increase other Costs • Customer support can be very expensive. Less bugs = less calls. • Customers will look for more reliable solutions. • Software organizations must perform cost benefit analysis’ to determine how much to spend on testing.

48. Problems with Testing Since it is impossible to find every fault in a software system, bugs will be found by customers after the product is released.

49. Another Problem In many software companies, testers are ill-equipped to test software. For example: My last co-op firm (which will remain unnamed). • Testing done almost entirely by untrained co-ops. • Testers were responsible for creating black-box test plans without being given formal specifications. • Testers were not provided with tools to automate test plans.

50. Reasons that Bugs Escape Testing • User executed untested code. • User executed statements in a different order than was tested. • User entered an untested combination of inputs. • User’s operating environment was not tested.