1. 1 Lecture 21 Final Exam Preparation CS 4310: Software Engineering

2. 2 Final Exam Details Final Exam is 15% of your grade for the class Same format as the Midterm Exam Short answer, multiple choice Should take about an hour to complete but you will have the full 2 hours if you need it. Comprehensive exam covering the entire course NO diagramming required

3. 3 Pre-Midterm Review Lecture 12 Slides – Midterm Review Weeks 1-5 in the midterm review The lecture 12 slide set reviews the course notes for the midterm exam.

4. 4 Week Six Risk Management

5. 5 What is Risk Management? The proactive approach to reacting to project change: (1)Risk Identification (2)Communicate Risks (3)Monitor Risks (4)Risk Mitigation (5)Risk Contingency Planning

6. 6 Types of Risks Page 82 and 83 of the class notes Predictable Risks Strategic Risks Financial Risks Project Management Risks Technology Risks

7. 7 Managing Risk Manage projects to avoid risk: Open and visible software process => Avoid surprises Continual review of requirements Willingness to modify or cancel projects

8. 8 Risk Mitigation, Monitoring and Management Mitigation — how can you avoid the risk? Monitoring — what factors can you track that will enable you to determine if the risk is becoming more or less likely? Management — what contingency plans do we have if the risk becomes a reality?

9. 9 Risk Management Plan Pages 84-87 in the class notes. Read the example in the course notes. This is a good example for what goes into a Risk Management Plan and how one is created.

10. 10 Week Seven GUI and Prototype Design

11. 11 Analysis leads to Design  goals of the system  scenarios  properties of interest Analysis Design  identify the main events, actions and interactions  identify and define the main processes  identify and define the properties of interest  structure the processes into a design architecture  check properties of interest

12. 12 Design leads to the Design Document Design Design Document  identify the main data design (structures)  identify component-level design  identity software interface design  identity user interface design

13. 13 Design leads to Source Code Design Java  identify the main active entities  identify the main (shared) passive entities  structure the classes as a class diagram

14. 14 Software Design Strategies FUNCTIONAL OBJECT-ORIENTED DECOMPOSITION DESIGN The solution is expressed in terms of objects (self-contained entities composed of data and operations on that data) that interact by sending messages to one another. The problem is divided into more easily handled subproblems, the solutions of which together create a solution to the overall problem.

15. 15 Object-Oriented Design A technique for developing a program in which the solution is expressed in terms of objects -- self- contained entities composed of data and operations on that data. TextField setText...... getText Private data and method s setLayout add pack...... show Frame Private data and method s TextField Frame

16. 16 What is a Prototype? Prototypes should exhibit and make vivid and comprehensible the essential features of the system that is being designed, and of its style of user interface, i.e., its look and feel. Prototypes should suggest what the application will do, what its essential characteristics are, what it will look like, and how it is to be used.

17. 17 Prototypes are Used for Envisions Prototypes are used to help one visualize things that do not yet exist Prototypes are used for –Designing media, systems, and interfaces –Pre-testing media, systems, and interfaces –Presenting interface ideas

18. 18 Envision in Design Visualizing concepts Exploring alternatives Resolving feature details Developing interaction scenarios –Visually showing your USE CASE scenarios

19. 19 Envision in Pre-testing Can you read or interpret this? Can you follow this? Can you make this work? Do you understand what is going on? Is this the way you would do this? Does this suggest alternate approaches to you?

20. 20 Envision for Presentation and Discussion To interface designers, for discussion To programmers, to guide implementation To marketing and management, to guide product design and marketing decisions To users, to get early feedback

21. 21 Practical prototyping… Remain flexible –Remember that your first prototype will not be your last. If your design is to progress, you must be willing to iterate the idea over and over again. Materials/Implementation –Choose materials that are easy to manipulate, ones you feel comfortable using. –Make something that is pleasant to look at. –Allow for strength, create prototypes that can handle a lot of use. Reject ideas that are too fragile and complicated, whenever possible simplify.

22. 22 Use Prototyping to Animate Benefits Easy to discover problems for end-user –Suggest how the requirements may be improved May be used to develop system tests –Used later in the system validation process –Executable prototypes may be used for back-to- back testing with the final system May serve as a stop-gap system –When delaying in implementing final system Reveals requirements inconsistencies and incompleteness

23. 23 Test the prototype Scenarios and role-playing are no substitute for user testing. Test with users with similar backgrounds to your target users. Doing the design will give you a large set of expectations about what users will do with the design. Testing will reinforce or contradict your expectations. You learn from that process.

24. 24 Benefits of Testing Testing will expose problems You can then attack those problems in order of severity - and work on features in order of value Beware of interactions between design elements - fixing one may break another Design Prototype Evaluate

25. 25 Week Eight Software Metrics Quality Assurance Configuration Management

26. 26 Software Measurement and Metrics Software measurement is concerned with deriving a numeric value for an attribute of a software product or process This allows for objective comparisons between techniques and processes Although some companies have introduced measurement programs, the systematic use of measurement is still uncommon There are few standards in this area

27. 27 What is a Software Metric? Quantitative measure of the quality of software. Measure of the difficulty of testing, understanding, or maintaining a piece of software Measure of ease of using software Software complexity is measure of human performance Computational complexity is a measure of program performance (Algorithm complexity)

28. 28 Uses of Software Metrics 1.Identify parts of program most likely to be hard to work with (e.g. test, maintain, understand,...) 2.Aid in allocation of testing and maintenance resources 3.Predictors of size of effort or number of bugs 4.Feedback to programmers

29. 29 Classification of Software Metrics 1.Size Metrics 2.Logical Structure Metrics 3.Data Structure Metrics 4.Interconnection Metrics 5.Object-Oriented Metrics 6.Function Points

30. 30 Size Metrics The larger the more complex – There are many ways to define size of a program Lines of Code (LOC) Standard definition of LOC –Count number of lines and data definitions –Do not count comment lines –Count a line containing both a statement or part of a statement and a comment as an executable line.

31. 31 Problems with LOC Lack of a Standard definition for line of code. Counting types of lines. –Executable lines –Data definition –Comments –Blank line Application written in multiple language. Size variation due to individual programming style.

32. 32 Size Metrics Function Count -- Coarse measure of program size. –Function count is the number of functions in the program. –Attempts to define size in terms of the number of tasks the program performs. Problems with function count What is a function? Function count depends on how problem broken up Function count can be padded or made very small

33. 33 Function Points Weighted sum of following: 1.External inputs - provided by user that describe distinct application-oriented data (e.g. file names) 2.External outputs - items provided to user that generate distinct application-oriented data (e.g. reports) 3.External inquiries - interactive inputs requiring a response 4.External files - machine readable interfaces to other systems 5.Internal files - logical master files in the system

34. 34 Function Point Example Read the Function Point Example that starts on page 93 of the course notes. You don’t have to read or know how to apply complexity adjustment factors. You do need to know how to calculate the base function point count that is explained on pages 93-96.

35. 35 Quality Assurance & Management Concerned with ensuring that the required level of quality is achieved in a software product Involves defining appropriate quality standards and procedures and ensuring that these are followed

36. 36 What is Quality? Quality means that a product should meet its specification This is a problem for software systems –Tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.) –Some quality requirements are difficult to specify in an unambiguous way –Software specifications are usually incomplete and often inconsistent

37. 37 Quality Management Activities Quality assurance –Establish organizational procedures and standards for quality Quality planning –Select applicable procedures and standards for a particular project and modify these as required Quality control –Ensure that procedures and standards are followed by the software development team

38. 38 Standards are the key to effective quality management They may be international, national, organizational or project standards Product standards define characteristics that all components should exhibit e.g. a common programming style Process standards define how the software process should be enacted Quality Assurance and Standards

39. 39 Quality Control Checking the software development process to ensure that procedures and standards are being followed Two approaches to quality control –Quality reviews –Automated software assessment and software measurement

40. 40 A group of people examine part or all of a software system and its associated documentation. Code, designs, specifications, test plans, standards, etc. can all be reviewed. Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management. Quality Reviews

41. 41 Source Code Management Also known as Configuration Management Source Code Managers are tools that: –Archive your development files –Serve as a single point of entry/exit when adding or updating development files

42. 42 How Configuration Management Works Central database of source code, documentation, build tools Each file stored only once - all other versions are temps of that one copy To Make a Change –Check out the latest version of a file –Make the changes –Update the database

43. 43 Version Control Companies ship several products from the same source base When tracking down bugs you want to examine the code as it was when the product shipped

44. 44 Version Trees Each file in the database has a version tree Can branch off the version tree to allow separate development paths Typically there is a main path (trunk) for the next major version and the branches off of it are shipped versions for maintenance

45. 45 Week Nine Software Maintenance

46. 46 Modifying a program after it has been put into use Maintenance does not normally involve major changes to the system’s architecture Changes are implemented by modifying existing components and adding new components to the system Software Maintenance

47. 47 Why Maintenance? Software maintenance represents 67- 80 % of the total software costs Maintenance activities are divided into four classes: Adaptive – changes in the software environment Perfective – new user requirements Corrective – fixing errors (21% of all changes) Preventive – prevent problems in the future.

48. 48 Code Decay Positive feedback between –the loss of software architecture coherence –the loss of the software knowledge less coherent architecture requires more extensive knowledge if the knowledge is lost, the changes will lead to a faster deterioration Loss of key personnel = loss of knowledge Challenge: eliminate or slow code decay

49. 49 Servicing The program is no longer evolvable –it either decays or managers decide not to support evolution Changes are limited to patches and wrappers –less costly, but they cause further deterioration Process is very different from evolution –no need for senior engineers –programmer is assigned only part of the software to support –the process is stable

50. 50 Usually greater than development costs (2* to 100* depending on the application) Affected by both technical and non-technical factors Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult. Ageing software can have high support costs (e.g. old languages, compilers etc.) Maintenance costs

51. 51 Problems of Waterfall Requirements volatility Requirements may change during development by 30% or more This is the direct result of the team’s learning process Maintenance phase is not uniform Frequency of the changes in long lived systems peaks, then declines

52. 52 Extending Waterfall If changes can be anticipated at design time –They can be built in by a parameterization, encapsulations, etc. –Waterfall model still can be used However experience confirms: – Many changes cannot be anticipated by the original designers – Inability to change software quickly and reliably means that business opportunities are lost

53. 53 Evolutionary Software Rather than think of separate development and maintenance phases, evolutionary software is software that is designed so that it can continuously evolve throughout its lifetime

54. 54 Spiral Maintenance Model

55. 55 Project Conclusion Prototype Deliverable Options Disk Files (floppy or CDROM) Email Files (compressed) Provide URL information Other? I’m flexible.