1. CS 360 Lecture 20

2.  The software industry needs to take more responsibility for its products  Products are sold or licensed with no guarantees about whether they work as advertised.  Time-to-market dominates much of software development.  We know how to develop much more reliable and secure software, but reliability and security often have low priority in business plans.  Compare:  The car industry (safety and reliability) 2

3.  Software Myths – Managers  We have standards and procedures for building software  So developers have everything they need  We have state-of-the-art software development tools  We buy the newest computers  If we’re behind schedule, we can add more programmers to catch up.  A good manager can manage any project. 3

4.  Software Myths – Client  A general statement of requirements/objectives is sufficient to begin writing programs.  Details can come later  Requirement changes are easy to accommodate because software is flexible. 4

5.  Software Myths – developer  If I miss something now, I can fix it later.  Once the program is written and running, my job is finished.  Until a program is running, there is no way to assess quality.  The only deliverable for a software project is a working program. 5

6.  Software development projects can fail in many ways:  The software engineering triangle  Late  Over budget  Lack of function, full of bugs, bad performance  Changing circumstances for the project  Changing markets  Better alternatives  Changes of management  The biggest single source of problems is poor understanding between the client and the development team. 6

7.  Major computing projects are very complex.  Inevitably there are delays and failures.  Few organizations know how to manage risk and uncertainty.  The best project managers:  Manage to minimize risk  Have the confidence of their staff who keep them truthfully informed  Have the self-confidence to keep their seniors truthfully informed 7

8.  Manage projects to avoid risk  Open and visible software process  Avoid surprises  Continual review of requirements  Willingness to modify or cancel projects  Try for short phases each with deliverables 8

9.  Canceling a project  It is harder to cancel a project than to start it.  It is harder to withdraw a service than introduce it.  Considerations  Management of expectations  Users of the service need a migration strategy.  Technical staff must have a graceful path forward.  If a project has to be cancelled, do it as early as possible. 9

10.  Software development demands a high degree of professionalism.  Question:  Is software development a branch of engineering? 10

11.  A definition of engineering  The profession of:  creating cost-effective solutions, to practical problems, by applying scientific knowledge, and established practices, building things, and taking responsibility for them!  With this definition, software development is clearly engineering 11

12.  A second defini1on of engineering  A professional who is licensed by a professional society, based on a set educational programs with a standard body of knowledge and specified experience, who is the only person permitted to oversee certain tasks.  This definition of engineering makes it is hard to see it applied to software development 12

13.  Part craft -- part engineering  Evolving body of expertise  ACM conclusion:  Software Engineering is too much of a craft, too uncertain, and changing too much for the apparatus of a profession  Who has the expertise to define a formal Body of Knowledge?  What would be in an accreditation exam? 13

14.  Recommended and jointly approved by the ACM and IEEE-CS as the standard for teaching and practicing software engineering.  http://www.acm.org/about/se-code http://www.acm.org/about/se-code 14

15.  The Code contains eight Principles related to the behavior of and decisions made by professional software engineers, including  practitioners  educators  Managers and supervisors  Trainees and students  The Code prescribes these as obligations of anyone claiming to be or aspiring to be a software engineer. 15

16.  Principle 1: Public  SEs shall act consistently with the public interest.  Accept full responsibility for their own work  Approve software only if they have a well-founded belief that it’s safe, meets specifications, passes appropriate tests, and does not diminish quality of life, privacy, or environment  Be fair and avoid deception  Encouraged to volunteer professional skills to good causes and contribute to public education concerning software engineering  Principle 2: Client and Employer  SEs shall act in a manner that is in the best interests of their client/employer  Provide service in their areas of competence, being honest about their limitations  Never using software that is obtained illegally or unethically  Keep private any confidential information gained by their work  Never accepting outside work that would be detrimental to their primary employer 16

17.  Principle 3: Product  SEs shall ensure that their products meet the highest professional standards as possible  Strive for high quality, acceptable cost, and reasonable schedule while developing  Identify and address ethical, economic, cultural, legal, and environmental issues  Strive to follow professional standards, when available  Treat all forms of software maintenance with the same professionalism as new development  Principle 4: Judgement  SEs shall maintain integrity and independence in their professional judgment  Maintain professional objectivity with respect to any software they are asked to evaluate  Never engage in deceptive financial practices  Disclose to all concerned parties those conflicts of interest that cant be avoided  Refuse to participate private, governmental, or professional organizations where their employers or clients have undisclosed potential conflicts of interest. 17

18.  Principle 5: Management  SE managers and leaders shall subscribe and promote and ethical approach to the management of software development and maintenance  Ensure good management for any project on which they work  Ensure that developers are informed of standards being held to them  Never punish anyone for expressing ethical concerns about a project  Principle 6: Profession  SEs shall advance the integrity and reputation of the software profession  Help develop an environment favorable to acting ethically  Promote public knowledge of software engineering  Take responsibility for detecting, correcting, and reporting errors in software and documentation on which they work 18

19.  Principle 7: Colleagues  SEs shall be fair to and supportive of their colleagues  Assist colleagues in professional development  Review the work of others in an objective, properly-documented way  Encourage colleagues to adhere to the SE code of ethics and professional practice  Principle 8: Self  SEs shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession  Further their knowledge of developments in the analysis, specification, design, development, maintenance and testing of software and related documents  Improve their ability to create safe, reliable, and useful quality software at reasonable cost and time  Recognize that personal violations of this code are inconsistent with being a professional software engineer 19

20.  Organizations put trust in software developers  Competence:  Software that does not work effectively can destroy an organization.  Confidentiality:  Software developers and systems administrators may have access to highly confidential information.  Legal environment:  Software exists in a complex legal environment.  Acceptable use and misuse:  Computer abuse can paralyze an organization. 20