Show off what your subsystem can do

Transcription

1 Wrap-up Demos Plan for a 20 minute presentation with time for questions May want to have 2 person presentation teams: a presenter and someone running the software If your project can be decomposed into subsystems, can have more than 1 presentation team Show off what your subsystem can do Show several use cases that highlight your team s functionality Go through the steps slowly so the customer can follow Practice and do only what you planned Save anything that is risky for the end

2 Demos Order of presentations: Project Integration Database Data Analysis Access Control Can use one laptop and continue to add complexity Add customers, add fields, set permissions, etc. Have a back-up laptop (or 2) with your demo all set to go in isolation Tuesday, May 10, 10:30-12:30 CmpSci Building 140 Final team project, due May 12th All material for the project requirements high-level designs low-level designs well-documented code build plan test cases status report what is completed and well tested what remains to be done what you would have done differently

3 Final Project Can revise any of your documents Keep the originals available Indicate what is revised Give date of revision and describe the changes Team evaluation done by each team member Provide a ranking and grade for all members of your team (including yourself) Sally 1 B Fred 2 B Winston 3 C- Comments on how your group worked Comments and grade for your project manager Comments on the class (optional) Send to clarke@cs.umass.edu by May 12th

4 What I hope you learned: development process Understanding of the development process Requirements, HLD, LLD, Implementation, Testing Maintenance, maintenance, maintenance Plan for change! Importance/difficulty of doing requirements Developing and using a glossary Avoiding implementation bias Decomposing the issues What I hope you learned: design Benefit of high-level design Architectural design Separating implementation concerns from interface concerns Separation of concern Design Principles Separation of concern Information hiding/encapsulation

5 What I hope you learned: integration Most failures are due to integration problems Not only do the interfaces have to be right, but the underlying assumptions have to agree Should be worked out carefully at HLD Problems will always arise Need an integration strategy Incremental build plan What I hope you learned: testing process Perform coding, testing, and integration in parallel Plan your integration strategy! Testing does not improve quality of code, it determines the quality Testing never stops! Better understanding of testing criteria

6 Exam Not too difficult? How should we have organized error handling? There are several aspects of the class project that nicely support information hiding. Provide two examples and explain their benefits. (Extra credit for providing a good example and explanation of where the class project could have done this better.) Comments on the project What did we do right? Decomposition of the system and subsystems Support for adding new fields and their options Access control supported by filters What should we have done better? Preferences Error processing

7 What we didn t cover Project management Alternative development approaches What we didn t do Good test planning and testing Software inspections 2-3 person teams to review submitted artifacts

8 Safety Critical Systems Systems whose failures have catastrophic consequences Nuclear power plants pacemakers Telecommunications switching systems Power grid controllers Societal infrastructure is becoming very dependent on software systems Design for Safety Pay attention to safety requirements throughout design and development keep design simple user interface design is very important diversity different kinds of controls for different types of functions redundancy e.g., speedometer provides a graphical and numerical display keep humans in the loop Plan for testing and verification of safety-critical functionality

9 Safety systems Should humans override an automated system? Switzerland, 2002 Traffic controllers were wrong, TCAS was right (traffic collision avoidance systems) Pilot listened to controller, crashed Previous situation, TCAS was wrong Still had test simulator running Sent a simulated threat Pilot overrode the system Safety failures Usually caused by a combination of unexpected events More than one subsystem experiences a failure E.g., Japan nuclear power plant explosion Risks Digest Peter Neumann

10 Accreditation should computer science departments be accredited? should software engineers be certified/ licensed? should safety engineers be certified/licensed? If so, what should be required? Alternatives to Licensing Code of ethics Needs to be well accepted and backed by a professional society If followed, protects an individual against legal action Certification Building projects often overseen by a certified architect who oversees uncertified workers Legal system Must show that a project followed accepted best practices Who determines those best practices?

11 My opinion More realistic to certify software engineers of critical systems (Inter)National certification requirements Certification would need to be renewed at regular intervals Need (inter)national committee to recommend best practices AMA model Based on experimental studies Reviewed continually and updated Current standards efforts are not based on experimental evidence, but by committees with a vested interest in the outcome Code of Ethics IEEE ACM

12 IEEE code of ethics (short version) Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles: 1. PUBLIC - Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. Strive for excellence and always act professionally and ethically

13 Good luck in your careers