History of Computing - Software Engineering

History of Computing - Software Engineering
Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Way, Box U-255 Storrs, CT (860) 486–4818 (Office) (860) (CSE Office)

Overview Review the History of Software Engineering
A Brief Intro to Software Engineering with A pictorial (Comical) View of the Process The Three Eras of Software Engineering From In the Beginning: Personal Recollections of Software Pioneers, Robert L. Glass ISBN: , 328 pages December 1997, Wiley-IEEE CS Press A View of 20th & 21st Century SWE, Barry Boehm ICSE 2006 Keynote Address Open/Source Software Overview and History S. Gokhale, Assoc. Prof, CSE Software Engineering Code of Ethics John Eveland & John Hoffstatter Software Engineering Steve’s Done

Brief Intro: What is Software?
Software is the Definition and Organization of a Set of Tasks and Functionality Encapsulated into a Form that is Executable on a Computer What are Different Types of Software? Commercial-Off-the-Shelf (COTS) Government-Off-the-Shelf (GOTS) Legacy: Written in an “Old” Programming Language Cobol, PL/1 (Y2k), Fortran, C and C++! Client vs. Server Software (Javascript) Database Management Systems/Applications New Languages: Java, Perl, Python New Mobile Platforms: Android, iOS Standards: XML, RDF, OWL, etc.

Definition of Software Engineering
IEEE definition: The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software. Roger S. Pressman’s definition (UConn PhD): Software engineering is the technology that encompasses a process, a set of methods and an array of tools. (Software Engineering: A Practitioner’s Approach) Parnas’s definition: Multi-person construction of multi-version software (Parnas 1978) Several definition. Look at the last one. It recognizes that a software product is much more complex and beyond the grasp of a single individual. As a result, a number of people are expected to work on the pieces of a software product in a cooperative fashion. Also, some of these people may leave the project, and may be replaced by newer engineers, in which case, the project has to lose the know how of that engineer. Also, a software product may have many versions and we need to manage these versions. Thus, SE is also a management activity in addition to the implementation activity.

What is Software Engineering?
Engineering: The Application of Science to the Solution of Practical Problems Software Engineering: The Application of CS to Building Practical Software Systems Programming Individual Writes Complete Program One Person, One Computer Well-Defined Problem Programming-in-the-Small Software Engineering Individuals Write Program Components Team Assembles Complete Program Programming-in-the-Large

What is Software Engineering?
The Application Of Engineering To Software Field of CSE Dealing with Software Systems Large and Complex Built By Teams Exist In Many Versions Last Many Years Undergo Changes Definitions: Application of a Systematic, Disciplined, Quantifiable Approach to the Development, Operation, and Maintenance of Software (IEEE 1990) Multi-person Construction of Multi-version Software (Parnas 1978)

Why Software Engineering?
Program Complexity Transcends Individual or Lone Programmer Software Engineering Targeted for Constructing Large Software Applications Defining Problem Clear and Completely Tools and Techniques to Support Process Team-Oriented Experience Software Engineering must Evolve to be an Engineering Discipline Software Engineering Must Promote and Support Multi-Person Construction of Multi-Version Software

Software Engineering - Historically
“Early Days” 1950’s Programmers Wrote Programs Early 1960’s - Very Large Software Projects Constructed by “Experts” Mid-Late 1960’s - Advent of Large Commercial Software Applications Large Systems Involved Teams of Individuals Coining the Term “Software Engineering” Towards a Software Engineering Discipline Individuals Couldn’t see “Big Picture” Increase in Communication Time Personnel Changes Impact on Productivity SE: Management, Organization, Tools, Theories, Methodologies, Techniques, etc.

Computing: A Historical Perspective
Early era of computer/software evolution: General-purpose hardware became commonplace Software was custom-designed for each application with a relatively limited distribution Product software (that is, programs to be sold to one or more customers) was in its infancy Second era of computer/software evolution: Multiprogramming and multi-user systems introduced human-machine interaction Real-time systems could collect, analyze and transform data from multiple sources Advances in on-line storage led to the first generation of database management systems Use of product software and the advent of “software houses” Early era – a single person wrote software for his/her own use. Usually, a mathematical problem was solved. The problem was well understood, and well within the grasp and comprehension capability of a single individual. Second-era – product software, that is now the user of the software and the developer was different. Also, software development organizations started producing applications with a general appeal, rather than applications that were tailored to the needs of a specific party. For example, word processing applications. Also, new storage capabilities led to the development of DBMS to store data efficiently, and to manage multiple people accessing the data simultaneously.

Third era of computer/software evolution: Distributed system greatly increased the complexity of computer-based systems Advent and widespread use of microprocessors Computers readily accessible to the public at large, rather than privilege of chosen few Fourth era of computer/software evolution: Moved away from individual computers and computer programs and toward the collective impact of computers and software Powerful desk-top machines controlled by sophisticated operating systems, networked locally and globally, and coupled with advanced software applications Internet exploded and changed the way of life and business Distributed system technology, a computer application need not run on a single computer, but could run on a collection of computers, and exploit the power offered by the collection. So even if a single computer was not powerful enough to solve a problem, a collection of computers might be. Also, if we were to get a single computer with the necessary power, it may be expensive, but a collection might not be. Also, the economic considerations allowed individual users to have computers. Fourth era – networked computers, communicating over LANs and WANs, can access data and content miles and miles away. Exploision in the scope, and breadth of software apps.

Are we in a Fifth Era of Computing Today? Mobile Computing Scripting Languages Platform Independent Environments Sencha Touch (html5) and Titanimum (Javascript) Touch Screens, Interactive Computing Phones, Tablets, Watches, Glasses, What’s Next? Wireless Anywhere Access Pervasive into Wide Range of Products from Cars to TVs to Microwaves What will be the Next Great Improvement? Distributed system technology, a computer application need not run on a single computer, but could run on a collection of computers, and exploit the power offered by the collection. So even if a single computer was not powerful enough to solve a problem, a collection of computers might be. Also, if we were to get a single computer with the necessary power, it may be expensive, but a collection might not be. Also, the economic considerations allowed individual users to have computers. Fourth era – networked computers, communicating over LANs and WANs, can access data and content miles and miles away. Exploision in the scope, and breadth of software apps.

Computing: A historical perspective
Fifth Era? Powerful desktops Internet Software apps. Fourth era Distributed systems Microprocessors PC-based systems Third era Multi-programming/multi-user Database Management Systems Software houses Second era General-purpose hardware. Custom software Early era 1950 1960 1970 1980 1990 2002

Key SWE Concepts - Abstraction

Key SWE Concepts - Encapsulation

Key SWE Concepts - Inheritance

A Comic View of SWE!

What are Software Engineering Processes?
Software Production Process Models Focus on the “How” of Software Development Stages, Phases, Steps: Methodology Varied Process Models Waterfall Model (oldest)/Evolutionary Model Transformation Model/Spiral Model UML Unified Process/Agile Model (newest) Other Process Issues Configuration Management/ Standards Production Models Focus on the Software Lifecycle Emphasizing the Process from Start to Finish

Waterfall Process Model
Grandfather of All Models Requirements Analysis and Specification What is Major Disadvantage? Design and Specification 50 % TIME & COST Coding and Module Testing Integration and System Testing Delivery and Maintenance 50 %

What are Software Requirements?

Software Lifecycle of Waterfall Model
Requirements Analysis and Specification What is the Problem to Solve? What Does Customer Need/Want? Interactions Between SE and Customer Identify and Document System Requirements Generate User Manuals and Test Plans Design and Specification How is the Problem to be Solved? High-Level Design Determine Components/Modules Transition to Detailed Design Detail Functionality of Components/Modules

Software Lifecycle of Waterfall Model
Coding and Module Testing Writing Code to Meet Component/Module Design Specifications Individual Test Modules in Isolation Drivers and Stubs to Simulate Behavior Integration and System Testing Integration of Components/Modules into Subsystems Integration of Subsystems into Final Program Delivery and Maintenance System Delivered to Customer/Market Bug Fixes and Version Releases Over Time

Pervasiveness of Software
Software is an important growing component of several systems in diverse domains : Power trains of GM cars contain 30 lines of code (LOC) Electric razors contain 2 KLOC TV sets contain 500 KLOC. Space shuttles and military aircraft systems thousands of KLOC. Demand for larger software systems is exponential: F4 had no digital computer and software (Early 70’s) F16A had 50 digital processors and 135 KLOC (Late 70’s) F16D had 300 digital processors and 236 KLOC (Late 80’s) B-2 has over 200 digital processors and 5000 KLOC What will be Impact of Mobile Computing? Smartphone/Tablet Hybrid? Will Laptops Dissappear?

Software Development Problems
Software costs are increasing as hardware costs continue to decline. Hardware costs vs. Software costs Hardware technology has made great advances. Simple and well understood tasks are encoded in hardware. Least understood tasks are encoded in software Demands expected of software are growing Size of the software applications is also increasing. Hardware costs Software costs Previously h/w costs dominated, s/w costs were trivial. But now software costs dominate. The total cost of the applications on your PC exceeds the cost of the hardware on which those applications sit. Because of the flexible nature of the software (can be changed easily), our tendency is to encode the least understood, and uncertain tasks in software, whereas the simple and well understood tasks in hardware. As a result, the size of the software applications grows, and these applications become inherently complex, increasing the cost even further. Time

Software development times are getting longer and longer and maintenance costs are getting higher and higher 3% 8% 7% 15% 67% Requirements % Design % Implementation -- 7% Testing % Maintenance % It takes a long time to understand the requirements of a software system, and then subsequently design and implement the software system. However, it takes much longer to test the system to ensure that it satisfies the user requirements. Software systems live much longer than is originally expected. In fact, a number of applications which were developed in the 1970s (often known as legacy applications) are being used even today. However, these applications have undergone many changes or have evolved. The changes made to the software after it has been released is referred to as maintenance of the software. Today, software maintenance is the most time and cost consuming activity of the software application. If the original requirements are not well understood, then that increases the need for maintenance even further, since it is discovered after release that the software application does not perform the intended tasks. In fact, over 80% of the errors that need to be fixed during testing and during maintenance is the result of poorly understood requirements. Most of the money and effort spent in testing and maintenance. 85% of errors are introduced during requirements analysis and design.

Relative costs to fix errors Cost to fix an error increases as it is found later and later in the software lifecycle. Cost It pays to discover errors sooner than later. If an error is discovered in the requirements phase, then, it is much less costly to fix an error, than when an error is discovered after the software system has been put into operation. Misunderstood requirements is the most common cause of error in a software product, and is often not discovered until the software system has been released and has been used by the customer. Design Testing Maintenance Requirements Implementation

What software engineering is and is not..
Software engineering is concerned with “engineering” building and modifying practical software systems: On time Within budget Meeting quality and performance standards Deliver features desired/expected by the customer Software engineering is not.. Just building small or new systems Hacking or debugging until it works Easy, simple, boring or even pointless! Issues haven’t really surfaced in learning to program Transformation/translation of a program to “software” The primary concern of software engineering is to facilitate the creation of large and complex software systems that are delivered to the customers as planned, and within the original cost estimates. Also, these systems must be capable of providing the functionality expected by the user, as well as meet the non functional requirements. It must be relatively easy to perform maintenance on the software system. All the design decisions must be well documented, and the system must be easy to use for the users, and easy to understand by the developers who will be subsequently working to modify the system. SE is often confused with programming. However, the main task of programming is to explore and build new systems. These new systems are small enough that they could be built by a single programmer. The programmer may spend a number of sleepless nights hacking until the program works. As a result, most programmers often have this misconceived notion that if they know how to program, then the study of software engineering is quite trivial and a waste of time. However, in SE one has to deal with issues that the programmers haven’t been exposed to. Thus, SE seeks to transform a program into a software product.

The Waterfall Model

From Waterfall to Agile

The Agile Manifesto

Agile Development

History of Software Engineering Three Eras of SWE
From In the Beginning: Personal Recollections of Software Pioneers Robert L. Glass ISBN: 328 pages December 1997, Wiley-IEEE Computer Society Press

The Pioneering Era ( ) New computers were coming out almost every year or two, rendering existing ones obsolete. Software people had to rewrite all their programs to run on these new machines. Programmers did not have computers on their desks and had to go to the "machine room".

The Pioneering Era - 2 Jobs were run by
signing up for machine time or by operational staff. putting punched cards for input into the machine's card reader and waiting for results to come back on the printer. The field was so new that the idea of management by schedule was non-existent. Making predictions of a project's completion date was almost impossible.

The Pioneering Era - 3 Computer hardware was application-specific. Scientific and business tasks needed different machines. Due to the need to frequently translate old software to meet the needs of new machines, high-order languages like FORTRAN, COBOL, and ALGOL were developed.

The Pioneering Era - 4 Hardware vendors gave away systems software for free as hardware could not be sold without software. A few companies sold the service of building custom software but no software companies were selling packaged software.

The Pioneering Era - 5 The notion of reuse flourished. As software was free, user organizations commonly gave it away. Groups like IBM's scientific user group SHARE offered catalogs of reusable components. Academia did not yet teach the principles of computer science. Modular programming and data abstraction were already being used in programming.

The Stabilizing Era (1965-1980)
The whole job-queue system had been institutionalized and so programmers no longer ran their jobs except for peculiar applications like on-board computers. To handle the jobs, an enormous bureaucracy had grown up around the central computer center. The major problem as a result of this bureaucracy was turnaround time, the time between job submission and completion. At worst it was measured in days.

The Stabilizing Era - 2 IBM 360 signaled the beginning of the stabilizing era. Largest software project to date ending the era of a faster and cheaper computer emerging every year or two. Software people could finally spend time writing new software instead of rewriting the old. The 360 also combined scientific and business applications onto one machine. It offered both binary and decimal arithmetic. With the advent of the 360, the organizational separation between scientific and business application people came to diminish and this had a massive impact on the sociology of the field. Scientific programmers who usually had bachelor degrees felt superior to business programmers who usually held only associate degrees. One scientific programmer remarked: "I don't mind working with business programmers, but I wouldn't want my daughter to marry one!"

The Stabilizing Era - 3 The massive O/S, still coming largely free with the computer, controlled most of the services that a running program needed. The job control language JCL raised a whole new class of problems. The programmer had to write the program in a whole new language to tell the computer and OS what to do. JCL was the least popular feature of the 360. PL/I, introduced by IBM to merge all programming languages into one, failed. The demand for programmers exceeded the supply.

The Stabilizing Era - 4 The notion of timesharing, using terminals at which jobs could be directly submitted to queues of various kinds was beginning to emerge, meeting with some resistance from traditionalists. As the software field stabilized, software became a corporate asset and its value became huge. Stability lead to the emergence of academic computing disciplines in the late 60's. However the software engineering discipline did not yet exist.

The Stabilizing Era - 5 Many “high-hype” disciplines like Artificial Intelligence came into existence. As these new concepts could not be converted into predicted benefits, the credibility of the computing field began to diminish. "Structured Programming" burst on the scene in the middle of this era. Standards organizations became control battle grounds. The vendor who defined the standards could gain significant competitive advantage by making the standards match their own technology.

The Stabilizing Era - 6 Although hardware vendors tried to put a brake on the software industry by keeping their prices low, software vendors emerged a few at a time. Most customized applications continued to be done in-house. Programmers still had to go to the "machine room" and did not have computers on their desks.

The Micro Era (1980-Present)
The price of computing has dropped dramatically making ubiquitous computing (i.e., computing everywhere) possible. Now every programmer can have a computer on his desk. The old JCL has been replaced by the user-friendly GUI.

The Micro Era - 2 The field still has its problems.
The software part of the hardware architecture that the programmer must know about, such as the instruction set, has not changed much since the advent of the IBM mainframe and the first Intel chip. The most-used programming languages today are between 15 and 40 years old. The Fourth Generation Languages never achieved the dream of "programming without programmers" and the idea is pretty much limited to report generation from databases. There is an increasing clamor though for more and better software research.

Professional and ethical responsibility
Software engineering involves wider responsibilities than simply the application of technical skills. Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. Ethical behaviour is more than simply upholding the law.

Issues of professional responsibility
Confidentiality Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence.

Issues of professional responsibility
Intellectual property rights Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. Computer misuse Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

Ethical Dilemmas Disagreement in principle with the policies of senior management. Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system. Participation in the development of military weapons systems or nuclear systems.

A View of 20th and 21st Century Software Engineering
Barry Boehm ICSE 2006 Keynote Address May 25, 2006

Outline Motivation and Context A 20th Century View A 21st Century View
Conclusions Timeless principles and aging practices 05/25/06 © USC-CSE

Motivation and Context
Working definition of “software engineering” Importance of historical perspective We are losing our history Some historical perspectives 05/25/06 © USC-CSE

“Software Engineering” Definition - Based on Webster definition of “engineering”
The application of science and mathematics by which the properties of software are made useful to people Includes computer science and the sciences of making things useful to people Behavioral sciences, economics, management sciences 05/25/06 © USC-CSE

Why Software Projects Fail - Average overrun: 89
Why Software Projects Fail - Average overrun: 89.9% on cost, 121% on schedule, with 61% of content 05/25/06 © USC-CSE

Importance of Historical Perspective
Santayana half-truth: “Those who cannot remember the past are condemned to repeat it” Don’t remember failures? Likely to repeat them Don’t remember successes? Not likely to repeat them 05/25/06 © USC-CSE

We Are Losing Our History
Great people are gone Hopper, Mills, Royce, Dijkstra, Dahl, Nygaard, Weiser, … Relative inaccessibility of hardcopy literature Median ICSE 2005 paper has no reference before 77% have no references before 1980 05/25/06 © USC-CSE

Some Historical Perspectives
1996 Dagstuhl Workshop Historians: Aspray, Bergin, Ceruzzi, Mahoney, Tomayko, … Practitioners: Endres, Parnas, Randell, Ross, Shaw, … Provided perspectives and insights adapted here 2001 Software Pioneers conference and book (Broy, Denert; Springer) NSF/ACM IMPACT Project: impact of research on practice To date: Configuration Management, Programming Languages Coming: Reviews, Testing and Analysis, Design, Reuse, Middleware, Resource Estimation A Hegelian View (drafted at Dagstuhl workshop) Thesis, Antithesis, Synthesis 05/25/06 © USC-CSE

A Hegelian View of Software Engineering Evolution
05/25/06 © USC-CSE

1950’s Thesis: Engineer Software Like Hardware
Hardware-oriented: Software applications: airplanes, bridges, circuits Economics: Boehm supervisor, 1955 “We’re paying $600/hour for that computer, and $2/hour for you, and I want you to act accordingly.” Professional Societies: Association for Computing Machinery, IEEE Computer Society Software Processes: SAGE (Semi-Automated Ground Environment) 1 MLOC air defense system, real-time, user-intensive Successful development of highly unprecedented system Hardware-oriented waterfall-type process 05/25/06 © USC-CSE

The SAGE Software Development Process - (Benington, 1956) “We were successful because we were all engineers”. 05/25/06 © USC-CSE

1960’s Antithesis: Software Is Not Like Hardware - Four Brooks factors plus two
Invisibility: like the Emperor’s Magic Cloth Complexity: Royce, “for a $5M procurement, need a 30-page spec for hardware, and a 1500-page spec for software” Conformity: executed by computers, not people Changeability: up to a point, then becomes difficult Doesn’t wear out: different reliability, maintenance phenomena Unconstrained: can program antigravity, time travel, interpenetration, … 05/25/06 © USC-CSE

1960’s Antithesis: Software Crafting
Flexible materials, frequent changes as above SW demand exceeded supply of engineers Music, history, art majors Counter culture: question authority Cowboy programmers as heroes Code-and-fix process Hacker culture (Levy, 1984) Collective code ownership Free software, data, computing access Judge programmers by the elegance of their code 05/25/06 © USC-CSE

1960’s Progress and Problems
Better infrastructure: OS, compilers, utilities Computer Science Departments Product Families: OS-360, CAD/CAM, math/statistics libraries Some large successes: Apollo, ESS, BofA check processing Problems: 1968, 1969 NATO Reports Failure of most large systems Unmaintainable spaghetti code Unreliable, undiagnosable systems 05/25/06 © USC-CSE

1970’s Antithesis: Formal and Waterfall Approaches
Structured Methods Structured programming (Bohm-Jacopini: GO TO unnecessary) Formal programming calculus: Dijkstra, Hoare, Floyd Formalized Top-Down SP: Mills, Baker Waterfall Methods Code and fix too expensive (100:1 for large systems) Precede code by design (De Marco SD, Jackson JSD/JSP) Precede design by requirements (PSL/PSA, SA, SREM) 05/25/06 © USC-CSE

The Royce Waterfall Model (1970) - Explicit feedback - “Do it twice”
05/25/06 © USC-CSE

Increase in Software Cost-to-fix vs. Phase (1976)
1000 1000 Larger Software Projects 500 500 IBM-SSD • 200 200 GTE • 100 100 Relative cost to fix defect Relative cost to fix defect 80% • • • • 50 50 Median (TRW Survey) 20% SAFEGUARD • • • 20 20 • • Smaller Software Projects 10 10 • • • 5 5 • • • 2 2 1 1 Requirements Design Code Development Requirements Design Code Development Acceptance Operation Acceptance Operation test test test test Phase in Which defect was fixed Phase in Which defect was fixed 05/25/06 © USC-CSE

1970’s: Problems with Formal Methods
Successful for small, critical programs Largest proven programs around 10 KSLOC Proofs show presence of defects, not absence Defects in specification, proofs happen Scalability of programmer community Techniques require math expertise, $500/SLOC Average coder in 1975 survey: 2 years of college, SW experience Familiar with 2 languages, applications Sloppy, inflexible, in over his head, and undermanaged 05/25/06 © USC-CSE

Large-Organization HW/SW Cost Trends (1973)
05/25/06 © USC-CSE

1970’s: Problems with Waterfall Model
Overly literal interpretation of sequential milestones Prototyping is coding before Critical Design Review Mismatch to user-intensive systems Heavyweight documentation hard to review, maintain 7 year project with 318% requirements change Milestones passed but not validated Mismatch to COTS, reuse, legacy SW Bottom-up vs. top-down processes Scalability, cycle time, and obsolescence Months = for sequential development 3000 KSLOC  5*14.4 = 72 months : 4 computer generations 05/25/06 © USC-CSE

05/25/06 © USC-CSE

1980’s Synthesis: Productivity, Reuse, Objects
Worldwide concern with productivity, competitiveness Japanese example: autos, electronics, Toshiba SW reuse Major SW productivity enhancers Working faster: tools and environments Working smarter: processes and methods Work avoidance: reuse, simplicity; objects Technology silver bullets: AI, transformations, DWIM, PBE Do what I mean; programming by example 05/25/06 © USC-CSE

Tools, Environments, and Process
Overfocus on programming: IPSEs to SEEs Requirements, design, planning and control, office support Formatted vs. formal specifications Process-driven SEEs Use process knowledge as tool integration framework Some overkill in locking people into roles Process execution support: “SW processes are SW too” What’s good for products is good for processes Reuse, prototyping, architecture, programming Process compliance support: Standards and CMMs 05/25/06 © USC-CSE

Reuse and Object Orientation
1950’s: Math routines, utilities 1960’s: McIlroy component marketplace, Simula – 67 1970’s: Abstract data types, Parnas program families 1980’s: Smalltalk, Eiffel, C++, OO methods, reuse libraries 1990’s: Domain engineering, product lines, UML, pub-sub architectures 2000’s: Model driven development, service oriented architectures 05/25/06 © USC-CSE

HP Product Line Reuse Investment and Payoff
05/25/06 © USC-CSE

No Silver Bullet: Brooks
Automated solutions are good for “accidental” software problems Simple inconsistencies, noncompliance, inferences They do not do well on “essential” software problems Changeability: adapting themselves to unanticipated changes Conformity: working out everything the computer needs to “know” Devoid of intuition, commonsense reasoning Complexity: integrating multiple already- complex programs Invisibility: communicating their likely behavior to humans Closest thing to silver bullet: great designers 05/25/06 © USC-CSE

© USC-CSE Individuals and interactions over process and tools
People: The Most Important Factor - SW engineering is of the people, by the people, and for the people 1970’s: Weinberg Psychology of Computer Programming 1980’s: COCOMO factor-of-10, Scandinavian Participatory Design, DeMarco-Lister Peopleware 1990’s – 2000’s: Importance emphasized in both Agile and CMM cultures Individuals and interactions over process and tools People CMM, Personal Software Process Overall migration from Reductionism toward Postmodernism (Toulmin) Universal towards Local General towards Particular Timeless towards Timely Written towards Oral 05/25/06 © USC-CSE

Dual 1990’s – Early 2000’s Antithesis: - Maturity Models and Agile Methods
Predictability and Control: Maturity Models Reliance on explicit documented knowledge Heavyweight but verifiable, scalable Time to Market and Rapid Change: Agile Methods Reliance on interpersonal tacit knowledge Lightweight, adaptable, not very scalable 05/25/06 © USC-CSE

Agile and Plan-Driven Home Grounds: Five Critical Decision Factors
Size, Criticality, Dynamism, Personnel, Culture Personnel (% Level 1B) (% Level 2&3) 40 15 30 20 20 25 Criticality (Loss due to impact of defects) Dynamism (% Requirements – change/month) 10 30 a: Many Lives b: Single Life c: Essential Funds d: Discretionary Funds e: Comfort a b 35 c 0.3 d 1.0 e 3.0 30 10 3 Agile 90 10 70 30 Plan-driven 50 100 30 300 10 Size (# of personnel) Culture (% thriving on chaos vs. order) 05/25/06 © USC-CSE

Other 1990’s – Early 2000’s Developments
Y2K and reverse engineering Risk- driven concurrent engineering Win-Win spiral with anchor points; Rational Unified Process Nature and importance of software architecture COTS, open source, and legacy software Software as the primary competitive discriminator 80% of aircraft functionality 05/25/06 © USC-CSE

Spiral Model and Concurrent Engineering
05/25/06 © USC-CSE

COTS: The Future Is Here
Escalate COTS priorities for research, staffing, education Software is not “all about programming” anymore New processes required * CBA: COTS-Based Application * Standish Group CHAOS 2000 (54%) 05/25/06 © USC-CSE

05/25/06 © USC-CSE

Mid-2000’s Synthesis: Risk-Driven Hybrid Products and Process
Increasing integration of systems engineering and SW engineering Increasing trend toward “soft systems engineering” Increasing focus on usability and value Fit the software and hardware to the people, not vice versa Model-driven development and service-oriented architectures Emergent vs. prespecifiable requirements Hybrid agile and plan-driven product and process architectures Encapsulate parts with rapid, unpredictable change Concurrent build-to-spec, V&V, agile rebaselining 05/25/06 © USC-CSE

MDA Adoption Thermometer - Gartner Associates, 2003
05/25/06 © USC-CSE

Risk-Driven Scalable Spiral Model: Increment View
05/25/06 © USC-CSE

The Future of Systems and Software
Eight surprise-free trends Increasing integration of SysE and SwE User/Value focus Software Criticality and Dependability Rapid, Accelerating Change Distribution, Mobility, Interoperability, Globalization Complex Systems of Systems COTS, Open Source, Reuse, Legacy Integration Computational Plenty Two wild-card trends Autonomy Software Combinations of Biology and Computing 05/25/06 © USC-CSE

Pareto 80-20 distribution of test case value [Bullock, 2000]
Actual business value 100 100 80 80 % of % of 60 60 Value Value Automated test Automated test for for generation tool generation tool Correct Correct 40 40 - - all tests have equal value* Customer Customer Billing Billing 20 20 5 5 10 10 15 15 Customer Type Customer Type *Usual SwE assumption for all requirements, objects, defects, … 05/25/06 © USC-CSE

Business Case for Value-Based Testing
05/25/06 © USC-CSE

Globalization: “The World is Flat” - Friedman, 2005
Information processing functions can be performed almost anywhere in the world Low-cost global fiber-optic communications Overnight global delivery services Significant advantages in outsourcing to low-cost suppliers But significant risks also Competitive success involves pro-actively pursuing advantages While keeping risks manageable 05/25/06 © USC-CSE

What does a SISOS look like? - Network-Centric Air Traffic Control
05/25/06 © USC-CSE

Integrated Enterprise Architectures
Federal Enterprise Architectural Framework (FEAF) DOD Architectural Framework (DODAF) Zachman Framework 05/25/06 © USC-CSE

Persistence of Legacy Systems
Before establishing new-system increments Determine how to undo legacy system 1939’s Science Fiction World of 2000 Actual World of 2000 05/25/06 © USC-CSE

Computational Plenty: Process Implications
New platforms: smart dust, human prosthetics (physical, mental) New applications: sensor networks, nanotechnology Enable powerful self-monitoring software Assertion checking, trend analysis, intrusion detection, proof-carrying code, perpetual testing Enable higher levels of abstraction Pattern programming, programming by example with dialogue Simpler brute-force solutions: exhaustive case analysis Enable more powerful software tools Based on domain, programming, management knowledge Show-and-tell documentation Game-oriented software engineering education 05/25/06 © USC-CSE

Wild Cards: Autonomy and Bio-Computing
Great potential for good Robot labor; human shortfall compensation 5 Senses, healing, life span, self-actualization Adaptive control of the environment Redesigning the world for higher quality of life Physically, biologically, informationally Great potential for harm Loss of human primacy: computers propose, humans decide Overempowerment of humans Accidents, terrorism, Enron California brownouts New failure modes: adaptive control instability, self-modifying software, commonsense reasoning, bio-computer mismatches V&V difficulties: cooperating autonomous agents, biocomputing Forms and timing of new capabilities still unclear 05/25/06 © USC-CSE

Timeless Principles (+) and Aging Practices (-)
From the 1950’s + Don’t neglect the sciences + Look before you leap (avoid premature commitments) Avoid inflexible sequential processes From the 1960’s + Think outside the box + Respect software’s differences - Avoid cowboy programming 05/25/06 © USC-CSE

From the 1970’s + Eliminate errors early + Determine the system’s purpose Avoid top-down development and reductionism From the 1980’s + These are many roads to increased productivity + What’s good for products is good for processes - Be skeptical about silver bullets 05/25/06 © USC-CSE

From the 1990’s + Time is money and value to people + Make software useful to people Be quick, but don’t hurry From the 2000’s + If change is rapid, adaptability trumps repeatability + Consider and satisfice all of your stakeholders’ value propositions - Avoid falling in love with your slogans (e.g. YAGNI) 05/25/06 © USC-CSE

For the 2010’s + Keep your reach within your grasp + Have an exit strategy Don’t believe everything you read “It’s true because I read it on the Internet” 05/25/06 © USC-CSE

Future Challenges for SW Engineering Education - Student careers go through 2050’s
Keeping courseware continually up-to-date Anticipating future trends and preparing students for them Separating timeless principles from aging practices Making small student projects relevant to large industry practices Participating in research; incorporating results in courses Helping students learn how to learn Offering lifelong learning to practitioners 05/25/06 © USC-CSE

Open Source and Free Software: An Overview Prof. Swapna Gokhale

What is open source/free software?
Software products distributed with terms so that users can: Use, modify, redistribute in any manner No royalty to the author Preserves the “moral right” of the author to be identified Open source vs. free software: Different definitions, but practically essential. Freedom or liberty to modify the source code, not free as in no cost – Freedom of speech not free lunch! Famous OSS systems: Apache & Mozilla Web browsers, Linux Operating System, PHP programming language, OpenOffice Productivity Suite, GNU Revolutionary software development paradigm Stiff competitor to proprietary or “closed source” software Free refers to the freedom to use it however you’d like, not to the free cost. OSS is not public domain or non-commercial software. Many commercial firms are now involved with OSS. How many of you have used software products? How do you acquire them? We buy them by paying money? Can we look at or modify the source code? No. There is a contemporary or an alternative or a competing source from which software products can be found. For these software products are “free” that is not only you do not pay anything for them, but you also have certain freedoms associated with their use. The software that you buy from vendors is called as proprietary or closed source software, or the product that you acquire from these repositories is called Open Source or Free Software. For a long time, OSS was dismissed as passing fad, something that would go away after a while. But the OSS revolution slowly picked steam, and now it is viewed as a serious alternative to proprietary or closed source software. OS applies not only to software, but many other domains. Wikipedia is another example. Process of creating scientific knowledge has worked that way for centuries. The important thing here is that the work derived from OSS must also remain OSS.

Evolution of open source/free software
Cooperation and sharing -- basic underlying human behavior First era – early 1960s to early 1980s Key aspects of operating systems and Internet developed at MIT, Berkley, Bell Labs and Xerox PARC Programmers shared basic operating code, and innovations at various sites. Second Era – early 1980s to early 1990s AT&T began enforcing its rights Formation of Free Software Foundation GNU – General Public License, developers must make the source code freely available. Users also must not impose restrictions on others Both academic and industrial researchers contributed and shared code. The approach in which OSS gets developed is through collaboration and cooperation within the community. But although OSS has gained attention only recently, this culture of cooperation and sharing is not new, and in fact has been around for a long time. Concept of sharing is old, only the scale is new.

Evolution of open source/free software
Third era – early 1990s to today : Rapid acceleration of open source activity Development of Linux Interactions between open source and commercial communities Different ways of licensing (imposing different restrictions) Where Does Java Fit into this Picture? Do you know History of Java? Sun Workstations (largest at one time) Developed in 1991 by James Gosling Released in 1995 with Inclusion into Netscape Attempt by Microsoft to Create Own Version (Blocked) Sun stopped Making Workstations (became Software Company) Oracle Purchased Sun OSS really picked up after the Internet became mainstream, because it allowed geographically distributed contributors to collaborate easily and seamlessly. The issue has become really important now, and commercial software companies are also beginning to take this type of development paradigm rather seriously.

Who contributes? Skewed contributors to development:
Most contributors make only one contribution Top two decile of contributors contribute about 81% Even more skewed contributors to bug fixing: Every individual contributing code, five report bugs “Elitist” open source process: Few important contributors, ascend to “core” group Many contributors are from outside major software development organizations Nearly 1.1 million people in North America OSS software is developed by many collaborators from many different countries. Generally, contributors like to call themselves hackers, in fact they take great pride in being referred to as hackers. No managers, no one is delegating tasks to others. Self motivated group of people. Each person takes on a task that he or she finds interesting or meets their needs, is commensurate with their level of skills, time and dedication. Elitist or meritocratic process, only after you have contributed a certain number of fixes or patches will you be allowed to commit to the code core base.

How to contribute to OS/FS?
User-oriented contributions: Providing feedback Helping new users Recommending the project to others Requesting new features Product-oriented contributions: Testing and reporting or fixing bugs Writing and updating software Other types of contributions: Creating artwork Writing or updating documentation Translating Improving the product, attracting more users by helping new users, sharing your experiences, answering questions, providing help with a specific set of features. OSS projects will survive only if there’s a community of users around it, so attracting new users is very vital to the sustenance of an OSS project. You, as a new user, can help in this endeavor. Enhancing the user experience.

What motivates hackers? – Study I
Intrinsic motivation: Inherent satisfaction, not tangible compensation Doing for the “fun of it”, enjoying the challenge Enjoyment-based intrinsic motivation (“State of flow”) : Maximum enjoyment Intense focus and concentration Enjoying the activity regardless of the outcome Skills must match the challenge Sense of creativity Obligation/community-based intrinsic motivation: Strong sense of community and acting according to the norms of the group “Hacker” culture – having fun while programming, and sharing code Now that this movement is rapidly picking up steam, the most puzzling question surrounding this movement is why would people contribute their time, effort, and intellect in developing/building something for free? What motivates the hackers? There are several studies conducted to understand the motivations of the hackers in OSS community. In the first study, the motivations were classified into two classes intrinsic motivation and extrinsic motivation. Intrinsic motivation refers to something internal, or something within the person that he/she finds rewarding or challenging. Many programmers note that this is their most creative experience. They achieve a state of flow, that is, they lose track of time when programming frequently. They find it intellectually stimulating. Many programmers also feel that source code should be open. There is no monetary or otherwise tangible reward. Various people contributing in various ways,

What motivates hackers? – Study I (contd..)
Extrinsic motivation: Benefit applied from the outside Immediate and delayed payoffs Immediate payoffs: Paid to participate Satisfying their particular need Firms might hire programmers to participate in OSS Delayed benefits: Career advancement Improving programming skills Intense code review by peers Volunteers vs. paid contributors. Paid contributors want to satisfy some of their work-related need, and also care about their professional status. Whereas volunteers care more about improving their professional skills or fulfill some non-work related need. Paid contributors spend about 2 days/week, while volunteers spend about 1 day/week.

What motivates hackers? – Study II
Social/community motives (60%): Learn and develop new skills Share knowledge and skills Participate in a new movement/revolution Career or monetary concerns (60%): Improve OS/FS products of other developers Improve job opportunities Earn reputation in OS community Developing, supporting, administrating OSS Political motives (65%): View software companies as “evil”, and limit their power Purely product-related motives (40%): Solve a problem that proprietary software cannot solve Get help in converting a good idea to a product What motivates hackers to give away code, help strangers with their problems? Is this behavior completely altruistic, or do developers gain something out of their contributions. Are these gains monetary or non-monetary? Many hypotheses, and some studies/surveys to understand what motivates developers to contribute their time and effort freely. Developers have different motives, and expect different rewards. Each individual may have more than one motive Some people also make money while developing, supporting or administrating OSS. The percentage, however, is very small. Results of this study are consistent with the previous one.

Incentives – Open source vs. commercial
Short-term compensation: Commercial organizations can provide salary to programmers Programmers working on open source projects have lower costs – familiarity, effort can also produce private benefit. Delayed reward (career advancement, signaling): Better performance assessment Full initiative – open source programmers are solely responsible, commercial programmers ‘ performance depends on their boss, Greater fluidity: Greater flexibility to shift from one project to other Open source experience favorable for securing venture capital: Founders of Sun, Netscape, Red Hat signaled their talent in the open source world Better performance assessment – outsiders can observe the source code, and judge for themselves whether the code works, whether it is difficult, whether it is well-written, the code was clever etc.

Skills learned – Technical skills
Algorithmic skills: Create new algorithms Handling code: Document code Design modular code Write code in a way it can be reused Reuse code written by the others Programming skills: Become familiar with different programming languages Basic and introductory programming skills General skills: Look for and fix bugs Run and maintain complex software systems OSS can provide a training environment to get your feet wet. The barrier to entry is very low, you can enter with little or zero programming experience, and try it out, to test whether you like it. Programming at several different types and levels – HTML, C, etc. The contribution does not only need to be about programming, it can be about writing documentation, fixing bugs, etc.

Skills learned – Management skills
Personal communication skills: Clearly articulate an argument Express personal opinions Accept and respond to criticism from others Planning skills: Clearly define and achieve targets Plan work and stick to a schedule Group and team skills: Coordinate one’s work with work of the others Evaluate the work of others Lead a project or a group of people Settle conflicts within a group Motivate people

Skills learned – Legal skills
Understand the various forms of intellectual property: Patents, copyrights, trademarks Different types of licenses : What each license allows and does not allow Liability issues What Potentially can Go Wrong? What Situations Does Use of OSS Have Concerns? What Kind of Software not Appropriate for OSS?

Skills learned – General skills
Language skills: Understand English Technical discussions Overview of documents in software technology Interpersonal skills: Understand and work with people from different cultures Interact with other people

OSS vs. commercial software
Market share: Software considered successful -- large marketshare Apache (open source) vs. IIS (proprietary) Linux is #2 OS used in web server Linux as popular as Windows for applications development More companies adopting OSS to control software costs Higher reliability: OSS has higher reliability than commercial software Bugs not fixed in commercial software, but fixed in OSS Linux more reliable than Windows, Apache more reliable than IIS Distributed and widespread software development – with enough eyeballs looking at the code, all bugs can be caught

OSS vs. commercial software
Performance: Linux has better performance than Windows Scalability: Linux dominates in the world of supercomputing What Underlies Andriod? Security: Most compromised sites are run by Windows Unpatched Linux systems are better than unpatched Windows Apache has better track record than IIS Total cost of ownership: OSS costs less than commercial software Includes costs involved in the overall lifespan of the software – initial purchase price, licensing costs, training costs, support costs, hardware costs, and upgrade costs if any. Doesn’t matter if the initial cost is low, what matters is how much is the total cost to own and use the system. Maintenance cost, upgrades, fixes, repairs, costs of failure, licensing costs, etc. Initial cost is low, maintenance is cheap, can run on old hardware, licensing cost is low, litigation ris Many times we want to get a product that has a higher chance of surviving. OSS has a higher chance of surviving because the number of developers working on the project is high. Also, the quality tends to be better because developers are also end users; many times somebody starts working on a OSS project because he or she perceives a need that CSS cannot satisfy.

What makes a successful open source project?
Modularity: Project should be divisible into small and well-defined tasks. Programmers can pursue these tasks without interacting Interesting/fun challenges to pursue: Exciting problems that need to be solved, attract programmers Leadership: Credible leader or leadership Starts and assembles a critical mass of code, but does less programming over time. Provides the vision Attracts programmers Keeps the project together – avoids forking or being abandoned

Interface between CS and OS software
Commercial firms initially dismissed OSS revolution Microsoft released “Halloween documents” Outlining the potential threat Source of great excitement and boost to the OSS movement See: What do commercial firms do to survive? Living symbiotically off of an open source project Code release Living symbiotically: Provide complementary functions and services not efficiently provided by OSS. Red Hat provides “support” for Linux Allocate a few programmers to open source projects “Reactive strategy”

Interface between CS and OS Software (contd..)
Code release: Release some of its proprietary code Sell complementary services, and boost profits – for example, consulting for a given piece of code

What OSS Does UConn Have?
Profiles Research Networking Software profiles.uconn.edu Developed by Harvard Medical School Maintained Version Supported by Recombinant

Where do we find open source software?
OpenDisc : Excellent source of software for Windows PC, Client, Web browser, Office Suite ( Mac Users: FreeSMUG suite CD, ( PortableApps: Portable Applications on USB Memory Stick LiveCDs : Boot an Intel PC using a Linux OS, without installing the OS, right off of the CD, Ubuntu, Knoppix Apache Software Foundation: GNU project – Free Software Foundation:

Where do we find open source software?
Freshmeat: Sourceforge: W3C Consortium: Codeplex:

Literature and resources
OSS Watch – Open Source Software Advisory Service: Perspectives on Free and Open Source Software, Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani and the references therein

OSS and software qualities
Performance and reliability requirements of OSS are similar to proprietary systems: Depend on the domain of the system Security – OSS is better : Many eyes viewing the software, can identify bugs that compromise the system Security – OSS is worse: Security through obscurity Secrecy of the source code is better Usability: Users have a chance to provide feedback early and often Sometimes developers themselves are users Both the attackers and defenders can see the code, and what is the ultimate impact of this situation – does it result in better or worse security?

OSS and software qualities
Maintainability, understandability, evolvability, and repairability are very important: OSS are in continuous state of evolution Verifability: Desirable, but difficult to achieve. Some OSSs have test suites, some don’t

OSS and principles Rigor and formality:
Difficult to find rigorous and formal requirements for OSS. Projects usually start to fulfill someone’s needs. Anticipation of change, Incrementality – OSS follows the principle of “release early and often” Functionality is developed incrementally, as the needs of the users change OSS projects evolve continuously Generality: Usually, OSS projects fulfill specific needs Difficult to find something that’s general

OSS and principles Modularity -- most important principle for the success of a OSS project. Project divided into small and well-defined tasks Programmers should be able to pursue these tasks without interacting

OSS and software design
OSS projects may not undergo a conscious design process: Most projects start off because to fulfill someone’s need. Yet, only the well-designed, modular projects survive OSS products should exhibit: High cohesion Low coupling Design may or may not be well documented Reverse engineer the design of your chosen OSS project.

OSS and requirements OSS model may differ from the traditional model Requirement analysis may be very ad-hoc Successful projects start with: Vision Prototype, embodying the vision Preferred mode of communication with community Community grows, list of requirements grows Additional requirements may come from anyone New requirements may be presented as a full-fledged implementation

OSS and requirements (contd..)
Requirements tradeoffs in traditional projects: Architect weighs conflicts and decides which to incorporate and which to postpone Requirements tradeoffs in OSS projects: Developer community has a say Core group of developers make these choices Core group takes on the role of system architect Core group is respected, process is same as traditional project

OSS and testing (Apache server)
Pre-release/pre-commit testing: Developer makes changes to the local copy Tests on his or her own server Comparable to unit test, thoroughness of the test depends on judgment and expertise of the developer No additional testing required prior to release Review may be required before committing Don’t break the build Inspections: Commit the change directly Produces a patch and mails it to developer list for review Changes to stable release – review before commit Changes to development release – review after commit Commit generally by the originator

OSS and software process models
OSS projects go through all the steps: Iteration possible at each step Sequencing may be different Requirements analysis may be ad-hoc: Successful projects start with a vision Artifact, that embodies the vision Preferred way of communicating top-level requirements with OSS community List of possible requirements grows with community: Additional requirements, new features from anybody Sometimes may be presented as implementation

OSS and software process models (contd..)
Resolving conflicts among requirements: Traditional: System architect resolves conflicts OSS: Developer community may vote Successful OSS projects, core group of respected developers to make choices Core group can have the same effect as system architect Implementation and testing: Similar to traditional projects, parallel with specification Individual developers are powerful: Carve out niche, free to design, implement, test as they see fit Competing designs and implementations, one will be selected Core group makes the selection

OSS and process models (contd..)
Maintenance, upgrade, release or porting: OSS projects rely on tools Version control, bug tracking, documentation, maintenance and distributed development OSS project that does not use sophisticated tools: Too small, or will eventually fail

OSS and cost estimation models
Existing estimation models cannot be used with OSS projects: Data collected from commercial CSS projects OSS projects have different platform and tools Existing data from long-term new projects, rather than maintenance projects OSS projects are maintenance-centric Issues in developing estimation models for OSS: Skewed effort by participants Participants do not keep track of the time expended Collaboration among geographically disperse participants Effort should be estimated on code changed, or any other metric?

OSS and SE tools Traditional projects not open to adopting SE tools: Do not fit the day-to-day needs Difficult to use, expensive Special purpose Successful OSS projects rapidly adopt SE tools: Many tools continue to be developed – issue tracking, code generation, automated testing, document generation, packaging Tools promote OSS practices ( One of the most important tools is configuration management.

Software Engineering Code of Ethics
John Eveland John Hoffstatter SELECTED SLIDES FROM CIS 6516_011 Managing Software Projects and Personnel

The need...

History and Goals 4 goals:
IEEE Board of Governors established steering committee (May, 1993). ACM Council endorsed Commission on Software Engineering (Late 1993). Joint steering committee established by both societies (January, 1994). 4 goals: Adopt standard definitions. Define required body of knowledge and recommended practices. Define ethical standards. Define educational curricula for undergraduate, graduate (Masters), and continuing education (for retraining and migration).

Research Review of available computing and engineering codes:
The American Association of Engineering Societies Accreditation Board for Engineering Technology ACM’s Code of Ethics for Professional Conduct The British Computer Society Code of Practice Institute for the Certification of Computing Professionals Engineer’s Council for Professional Development The IEEE Code of Ethics National Society of Professional Engineers Code of Ethics Project Management Institute Code of Ethics

Brief History Timeline
January International Task Force formed the Software Engineering Ethics and Professional Practice (SEEPP). July Initial version shown to professional societies including ACM’s SIGSOFT. November Version 3 published in IEEE-CS and ACM magazines. Version 4 presented to IEEE review process. October Version 5.2 unanimously adopted by ACM and IEEE.

8 Key Principles in Published Proposal:
“Software Engineering Code of Ethics” by Gotterbarn, Miller, and Rogerson (November 1997/Vol. 40, No. 11, CACM) Product Public Judgement Client and Employer Management Profession Colleagues Self

Principle 1: Products 1.01 Ensure adequate software specification
Understand specifications fully Ensure you are suitably qualified Ensure all goals are achievable Ensure proper methodology use Ensure good project management Ensure all estimates are realistic Ensure adequate documentation Ensure adequate testing and debugging Promote privacy of individuals Use data legitimately Delete outdated and flawed data Identify and address contentious issues Promote maximum quality and minimum cost Follow appropriate industry standards

Principle 2: Public 2.01 Disclose any software-related dangers
Approve only safe, well tested software Only sign documents in area of competence Cooperate on matters of public concern Produce software that respects diversity Be fair and truthful in all matters Always put the public’s interests first Donate professional skills to good causes Accept responsibility for your own work

Public 1.04. Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents.

Principle 3: Judgement 3.01 Maintain professional objectivity
Only sign documents within your responsibility Reject bribery Do not accept secret payments from the client Accept payment from only one source for a job Disclose conflicts of interest Avoid conflicting financial interests Temper technology judgments with ethics

Principle 4: Client and Employer
Provide services only where competent Ensure resources are authentically approved Only use property as authorized by the owner Do not use illegally obtained software Honor confidentiality of information Raise matters of social concern Inform when a project becomes problematic Accept no detrimental outside work Represent no interests adverse to your employer

Client & Employer 2.09. Promote no interest adverse to their employer or client, unless a higher ethical concern is being compromised; in that case, inform the employer or another appropriate authority of the ethical concern.

Principle 5: Management
Assure standards are known by employees Assure knowledge of confidentiality protocols Assign work according to competence Provide due process for code violations Develop fair ownership agreements Accurately describe conditions of employment Offer only fair and just remuneration Do not prevent a subordinate’s promotion Do not ask a person to breach this code

Management 5.01 Ensure good management for any project on which they work, including effective procedures for promotion of quality and reduction of risk.

Principle 6: Profession
Associate with reputable people Promote commitment of this code Support followers of this code Help develop an ethical environment Report suspected violations of this code Take responsibility for errors Only accept appropriate remuneration Be accurate and honest regarding software Place professional interests before personal Obey all laws governing your work Exercise professional responsibility Promote public knowledge of the subject Share software knowledge with the profession

Profession 6.07. Be accurate in stating the characteristics of software on which they work, avoiding not only false claims but also claims that might reasonably be speculative, vacuous, deceptive, misleading, or doubtful.

Principle 7: Colleagues
Assist colleagues in professional development Review other’s work only with their consent Credit fully the work of others Review others work candidly Give fair hearing to colleagues Assist colleagues’ awareness of work practices Do not hinder a colleague’s career Do not pursue a job offered to a colleague Seek help with work outside your competence

Colleagues 7.02. Assist colleagues in professional development.

Principle 8: Self 8.01 Further your own professional knowledge
Improve your ability to produce quality work Improve your ability to document work Improve your understanding of work details Improve your knowledge of relevant legislation Improve your knowledge of this code Do not force anyone to violate this code Consider code violations inconsistent with software engineering

Self 8.01. Further their knowledge of developments in the analysis, specification, design, development, maintenance, and testing of software and related documents, together with the management of the development process.

Preamble “Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance, and testing of software systems.” Prevalence of software in society provide significant opportunities to do good or cause harm. Ensure that efforts are used to do good. Not intended to be applied piecemeal.

Preamble - continued Not to be used to justify errors of omission or commission. Not a simple algorithm to produce ethical decisions. Software engineer must use judgment after thoughtful consideration of the 8 fundamental principles. Always use the public interest as the highest and governing principle.

Short version, 1 of 2 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.

Short version, 2 of 2 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.

More on Management Software engineers need to know the standards which they are held to Know policy for protecting confidential information Assign work after considering each individual’s skills Principle of team balance* Provide realistic quantitative estimates Function points & SLOC* Well defined cost models such as COCOMO*

Even more on management
Fair compensation Don’t prevent someone’s promotion if he/she is qualified Good programmers don’t always make good managers* Let the person progress if he shows the aptitude Don’t punish someone for expressing ethical concerns

Missing from the Code Where to get help in a dilemma?
Who to report violations to? Where to get advise and support in a confrontation with employer? Consequences of violating the code? Client and Employer – what do you do if their interests conflict? Provisions for updating the Code

Helpful sites and References:
ACM Professional Code of Conduct ACM Software Engineering Code of Ethics ACM Public Policy Statements Gotterbarn, D., Miller, K., Rogerson, S., “Software Engineering Code of Ethics”, Communications of the ACM 40, 11 (Nov. 1997), pp Code of Ethics is Approved”, Communications of the ACM 42, 11 (Oct. 1999), pp Gottenbar, D. “A Positive Step Toward a Profession: The Software Engineering Code of Ethics and Professional Practice”, AMC SIGSOFT Software Engineering Notes 24, 1 (Jan. 1999), pp. 9-14

Software Engineering Steve’s Done
Naval Postgraduate School, The Implementation of a Multibackend Database System (MDBS): An Exercise in Database Software Engineering Applied Software Engineering Concepts to DB D&D Psuedo Code for Algorithms Walkthroughs Utilized Chief Programming Teams Chief Programmer (CP) Responsible for Design and Critical Portions of Code Reports to Manager responsible for Administration Determines Needs for Programmers, Consultants Determines Tasks, Initiates/Controls Decisions Librarian -Maintains Software Repository Software, Program Libraries, Documentation

CP Team Structure Backup Programmer – Understudy of CP who Participates in Design/Code and can Take Over Other Programmers Aid in Design and Coding Number Depend on Size of Project Chief programmer Librarian Programmers Specialists Backup Programmers

Software Engineering Steve’s Done
UConn – CT Insurance Department Project Insurance Department (Hartford) Project Manager Full-Time Consultant 2 Support Developers (Web, Testing, etc.) UConn (Storrs) 3 Software Engineers (1 in Waterbury - Remote) hour/week Grad Students S. Demurjian and D.G. Shin (UConn Managers) We Utilized Mixed Control

Mixed Control Combines Prior Two Approaches to Emphasize their Advantages and Minimize their Disadvantages Consists of Three Groups of People Project Manager Senior Software Engineers Junior Software Engineers Senior Engineer Leads a Group of Juniors and Reports to a Project Manager Control Vested in the Project Manager and Senior Programmers Communication Decentralized Among Each Set of Individuals, Peers, and Their Immediate Supervisors

Mixed Control Team Structure
management structure communication pattern

CT Insurance Project Plan
Employed MS Project for Detailed Estimations of Effort Applied to a Schedule Estimations Occurred After Significant Amount of Development Accomplished Experience to Base Estimates More Precise Guesstimates Web Page Contains MS Project Plan (24 pages) Excel Spreadsheet on Hours/Timeline Where are we Today? Not Used Since Created (December 2003) Interesting to do a Post-Mortem on Planning …

CT Insurance Overall Plan
Nearly 3Year Period (9/2002 to 5/2005) 24 pages 8.5 by 11 inches 4 rows and 6 pages per row Entire Plan 5ft wide by 3 ft high Below is ½ of the first main portion of plan

Focused Plan for Consumer Affairs

2nd Portion of Plan

Scheduling – What are the Pieces?
Divisions Licensing Con. Aff. Mar. Con. Shared Tabs Classify Assign Inquiry Processing

CT Insurance Department Project
Insurance Department (Hartford) Project Manager Full-Time Consultant 2 Support Developers (Web, Testing, etc.) UConn (Storrs) 3 Software Engineers (1 in Waterbury - Remote) hour/week Grad Students S. Demurjian and D.G. Shin (UConn Managers) We Utilized Mixed Control – How? Four Teams (1a, 1b, 1c, 1d) Gentronics Consultant Teams Spanned Both Locations

CT Insurance Detailed Team Planning

History of Computing - Software Engineering

Similar presentations

Presentation on theme: "History of Computing - Software Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

History of Computing - Software Engineering

Similar presentations

Presentation on theme: "History of Computing - Software Engineering"— Presentation transcript:

Similar presentations

About project

Feedback