Lecture 21 Final Exam Preparation

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

2. Final Exam Details • Final Exam is 15% of your grade for the class • You will have the full 2 hours if you need it. • Comprehensive exam covering the entire course a higher focus past the midterm exam. • 1 class/object diagramming question where you will need to create a diagram. • No ERD or DFD diagramming.

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. Week Six • Risk Management

5. What is Risk Management? • The proactive approach to reacting to project change: • Risk Identification • Communicate Risks • Monitor Risks • Risk Mitigation • Risk Contingency Planning

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

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. 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. 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. Week Seven • GUI and Prototype Design

11. Analysis leads to Design • goals of the system • scenarios • properties of interest Analysis • 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 Design • check properties of interest

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

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

14. Software Design Strategies FUNCTIONAL OBJECT-ORIENTED DECOMPOSITION DESIGN The problem is divided into more easily handled subproblems, the solutions of which together create a solution to the overall problem. 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.

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

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

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

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

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

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

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

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

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

24. Week Eight • Quality Assurance • Configuration Management

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

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

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

28. Quality Assurance and Standards • 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

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

30. Quality Reviews • 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.

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

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

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

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

35. Week Nine • Software Maintenance

36. Software Maintenance • 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

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

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

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

40. Maintenance costs • 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.)

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

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

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

44. Spiral Maintenance Model

45. Project Conclusion • Prototype Deliverable Options • Disk Files (floppy or CDROM) • Email Files (compressed) • Provide URL information • Other? I’m flexible. • Class presentations on Thursday • 10 minutes per team.