CS 4310 Software Engineering Lecture 21 Final Exam

CS 4310: Software Engineering Lecture 21 Final Exam Preparation 1

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

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

Week Six • 4 Risk Management

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 5

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

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

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? 8

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

Week Seven • 10 GUI and Prototype Design

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

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 12 Design Document

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 13

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

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

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 16

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

Envision in Pre-testing • • • 18 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?

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 19

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

Use Prototyping to Animate Benefits 21 • 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-toback testing with the final system • May serve as a stop-gap system – When delaying in implementing final system • Reveals requirements inconsistencies and incompleteness

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

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

Week Eight • Quality Assurance • Configuration Management 24

Quality Assurance & Management 25 • 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

What is Quality? • • 26 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

Quality Management Activities • • • 27 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

Quality Assurance and Standards • • 28 Standards are the key to effective quality management They may be international, 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 Control 29 • 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

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

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 31

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 32

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 33

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 34

Week Nine • Software Maintenance 35

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 36

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

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 38

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 39

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. ) 40

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 41

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 42

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 43

Spiral Maintenance Model 44

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