Software Engineering Introduction Pepper with credit to both

Software Engineering Introduction Pepper (with credit to both Dr. Chays and Ian Sommerville book slides)

My Contact Info My office hours: ¡ Office: POST 103 1 rst Floor (or in lab Post 102) ¡ Office Hours: Monday 8: 20 - 8: 50; 11: 00 – 12: 00 ; 1: 00 – 2: 15 Wednesday 8: 20 - 8: 50; 11: 00 - 12: 00 Friday 8: 20 - 8: 50; 11: 00 – 12: 15 ¡ Email: pepper@adelphi. edu My phone: 516 -297 -5241 My Web: www. adelphi. edu/~pe 16132 Moodle: ecampus. adelphi. edu

Major Course Objectives Identify kinds of users, scenarios, and usecases in business systems ¡ ¡ ¡ for systems presented in class for one system you design for one system with you as the designated user Experiment with using both iterative (ex: Agile) and plan based (ex: Waterfall) methodologies to design a new small system. The design documentation - UML diagrams ¡ Requirements analysis, select test cases, design and implement, test, and document. ¡ Use design patterns (briefly) ¡ Change management – GIT ¡

Why take this course Design code without explicit direction ¡ Code multiple classes that work together without the professor giving the design ¡ Some design patterns Work with users as you will in many businesses See how your coding skills may be used in business Get a feel for some different levels of career opportunities Acquire language to discuss the software process for successful design and for interviews Learn diagrams that help you communicate software design with users and programmers Learn how to test programs well and at many levels

Assignments Homework Exercises ¡- NOT ACCEPTED LATE ¡ Due before class starts Project - penalty for lateness ¡ Everyone is assigned to a development team of 3 people ¡ Each team will serve as a design/coding group plus also a user group for another team. ¡ Each team chooses one system to work with throughout the course. ¡ Partial team submissions accepted ¡ Writiing quality counts Business 1 Business 2 User team D&E&F A&B&C Tech team A&B&C D&E&F

Textbook Sommerville, Ian. Software Engineering, New York: Addison-Wesley, 2011 edition 8 or 9 or 10 ISBN of edition 10: 9780133943030 UML Distilled by Martin Fowler Practical Software Development Techniques. By Crookshanks, Edward Design Patterns, by Erich Gamma et al Object-Oriented Software Engineering, by Bernd Bruegge et al Project-Based Software Engineering: An Object. Oriented Approach, Evelyn Stiller et al The Mythical Man-Month, by Frederick Brooks,

Textbook Case studies A personal insulin pump ¡ An embedded system in an insulin pump used by diabetics to maintain blood glucose control. A mental health case patient management system ¡A system used to maintain records of people receiving care for mental health problems. A wilderness weather station ¡A data collection system that collects data about weather conditions in remote areas. Chapter 1 Introduction 7

Why do we need this course? Why engineer software? ¡ Can’t we just hack at it, until we get something that works? Many people/companies do this anyway… Answer: can’t hack it if we care about quality ¡ If a system is not put together in a wellorganized manner, the chance for bugs is greater Another Answer: You can’t just hack together a 106 LOC system ¡ Complex systems are impossible to build in an adhoc manner Some more Answers: Budget and Contract

Introduction: software quality Software is often buggy In critical applications, bugs can lead to drastic consequences ¡ Therac-25 malfunctions killed or severely injured several people in 1985 -87 ¡ Ariane 5 launcher crash on 4/6/1996 ¡ Airbus problems ¡ Banking software failures ¡ Healthcare Exchange http: //www. cio. com/article/2380827/developer -6 -software-development-lessons-from-healthcare-gov-s-failed-launch. html The main reason for bugs is enormous complexity of software Need techniques to cope with this complexity

Quality Issues Software is now an integral part of every facet of our societal infrastructure ¡ Air traffic control ¡ Telecommunication ¡ Financial infrastructure Poor quality software menaces the maintenance of that infrastructure Software is the "Grand Enabler" holding the key to scientific and engineering challenges ¡ Human genome project ¡ Space exploration ¡ Weather prediction

Why isn’t software quality up to snuff? deliver prototypes "leave it to the marketplace" unsophisticated consumers ¡ don't know what they want ¡ tolerate high failure rates "the computer is down" "user error" ¡ misled by "coverups" in banking, finance, communications ¡ lack of understanding of risks Year 2000 (Y 2 K) Web security

What is software? Code Various design documents User manuals Development plans, timelines, and budgets Maintenance documents The way of producing software (process)

Desirable qualities of software systems Reliability ¡ Performs the required functions correctly ¡ The rate of failures is low Maintainability ¡ Understandability ¡ Changeability ¡ Simplicity Reusability ¡ The solution to a problem should be as general as possible User friendliness Efficiency

Some interesting numbers - Quality Metrics About 25% of s/w projects fail ¡ Failure rate increases as the size of the project increases Costs about $100/LOC ¡ Ranges Typical programmer produces about 30 LOCs a day ¡ Ranges between $10 -$600 between 10 -100 LOCs 25 faults/KLOC ¡ Ranges between 3 -100 faults/KLOC

Software Failures - more interesting numbers Gartner found that 28% of IT projects with budget exceeding $1 million fail. The Standish Group, when considering projects of $10 million or more, said that ¡ 52% were challenged, meaning they faced budget, schedule or user expectation issues, ¡ 41% were failures ¡ 6. 4% were successful. http: //www. cio. com/article/2381459/regulati on/healthcare-gov-may-be-a--black-swan. html

Software costs Development costs ¡ generally measured in hundreds to thousands of dollars per delivered LOC many artifacts associated with a line of code ¡ testing and analysis is usually 50% of this cost Maintenance costs ¡ 2 -3 times as much as development

Software Costs Development costs reqts and design code 15% 35% testing 50% Full lifecycle costs code reqts/design testing maintenance

Models Software code is too complex to reason about it directly Need a higher level representation, called design ¡ Captures only the most important relevant characteristics of the problem ¡ Needs to capture the behavior of the problem accurately Software code must conform to its design

Software Engineering Name coined at the NATO Science Committee Conference, October 1968 Engineering-- established, scientifically sound practices that well trained practitioners follow Software Engineering-- the application of scientific knowledge to the development and maintenance of software systems Software-- ALL associated artifacts to assist with the development, operation, validation, and maintenance of programs/software systems ¡ e. g. , code, documentation, designs, requirements, user manuals, installation manuals, test cases, test results, bug reports, revision history, make files, . . .

Industry’s short term focus "bottom line orientation" ¡ emphasis on time to market not life cycle ¡ return on investment startups cannot invest in R&D until product established in marketplace ¡ without the R&D, takes too long for next or improved product ¡ market strategy driven by investors who want impressive short term gains

The nature of software Software is a complex, intricately interconnected data aggregate Software Development is the process of creating such a complex product, while continuously assuring that it remains consistent Software Engineering is the systematic design and management of the software development.

What is novel about software, compared to other fields of engineering? product is unprecedentedly complex application horizons expand too fast--with human demands/imagination construction is human-intensive solutions require unusual rigor extremely malleable--can modify the product all too easily

Barriers to engineering software Industry’s short term focus Shortage of skilled personnel Inadequate investment in R&D Poor technology transfer models Insufficient standards

Industry’s short term focus software houses ¡ intensely competitive ¡ often don't use own technology ¡ keep development cost down, fix later unsophisticated industries ¡ lack of technical expertise ¡ lack of administrative experience overselling the technology

Software Causing Disaster http: //www. wired. com/software/coolapps/new s/2005/11/69355? current. Page=all Ariane 5 - rocket ¡ Module from prior version of code not needed, but not removed ¡ Backup system fails for same reason as main system ¡ Failure sends directional commands, not seen as failure code but taken as direction ¡ Velocity exceeded maximum for 16 bit unsigned integer when converted from original 64 bit size

What do we need? Scientific basis Organized discipline R&D strategy Trained professionals Technology transfer strategies Quality control

High-level Goals of Software Engineering improve productivity ¡ reduce resources e. g. , time, cost, personnel improve predictability improve maintainability improve quality

How to increase Software Quality Treat software as a PRODUCT produced in a systematic way by a PROCESS designed and implemented to achieve explicit quality objectives ¡ Build quality in ¡ Define software product formally ¡ Define software process formally ¡ Reason about the product and process formally ¡ Incorporate validation as integral steps in the process ¡ Reuse when appropriate ¡ Consider incremental releases

Certification and Licensing? Currently, software engineering is not one of the 36 engineering professions recognized and licensed in the United States. 48 states prohibit using the term "engineer" without a license ¡ Texas has forced universities to stop MSSE ¡ Tennessee prohibits the use of "software engineering" in business literature and advertising ¡ New Jersey considered, but did not pass, a regulation that would have required licensing of all SW professionals IEEE/CS & ACM established Commission on Software Engineering in 1993 2009 Software Engineering Consortium ¡ NCEES/IEEE Principles and Practices Exam of Software in 2013 – Not required

Software Process Models • • • Software Process Activities General Model Types Specific Models

The software process Activities Needed ¡ Specification – defining what the system should do; ¡ Design and implementation (development) – defining the organization of the system and implementing the system; ¡ Validation – checking that it does what the customer wants; ¡ Evolution – changing the system in response to changing customer needs. A software process model is an abstract representation of a process. Chapter 2 Software Processes 31

Plan-driven and agile processes Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. (ex: waterfall) In incremental processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. (ex: Agile, Extreme Programming) In practice, most practical processes include elements of both plan-driven and agile There are no right or wrong software Chapter 2 Software processes. 32 Processes

No One Best Method Heterogeneity ¡ distributed systems across networks - different types of computer and mobile devices. Business and social change ¡ Business and society changes ¡ Emerging economies ¡ New technologies System types ¡ Embedded – like insulin pump system ¡ Information / transactional – like medical records ¡ Data collection – like Wilderness Weather system Developer skill levels Chapter 1 Introduction 33

#1 Waterfall Method – Plan based with Gates Requirements reqts. analysis System Design validation Coding (Implementation) Unit test Integration System Test Maintenance revalidation

Waterfall Model - Requirements-- a complete, consistent specification of what is needed ¡ Feasibility study Is it technically and financially feasible to build the system? ¡ Requirements elicitation and analysis What do the system stakeholders require or expect from the system? ¡ Requirements specification Defining the requirements in detail Requirements analysis Checking the validity, completeness and correctness of the requirements Risk Assessment

The requirements engineering process Chapter 2 Software Processes 36

Waterfall Model - Design design specifications--a description of how the requirements are to be realized ¡ high-level architectural design ¡ low-level detailed design validation ¡ traceability between requirements and design decisions ¡ internal consistency

A general model of the design process Chapter 2 Software Processes 38

Waterfall Model - Implement code--realization of the design in executable instructions code validation – Unit Test ¡ assure coding and documentation standards have been maintained ¡ internal consistency e. g. , syntactic analysis, semantic analysis, type checking, interface consistency ¡ consistency between design/requirements and code

Waterfall Model Integrate and System Test Integrate modules System testing--reveal problems, demonstrate behavior, assess reliability, evaluate non-functional requirements (e. g. , performance, ease of use) ¡ integration testing ¡ system testing ¡ acceptance testing ¡ regression testing ¡ testing validation adequacy of the testcases

Stages of testing Chapter 2 Software Processes 41

Testing phases in a plan-driven software process Chapter 2 Software Processes 42

Waterfall Model - Maintenance maintenance--the process of modifying existing software while leaving its primary functionality intact ¡ corrective maintenance-- fix problems (20%) ¡ adaptive maintenance-- add new functionality/enhance existing features (30%) ¡ perfective maintenance-- improve product (50%) e. g. , performance, maintainability Regression Test maintenance involves all the previous phases of the lifecycle

System evolution Chapter 2 Software Processes 44

Is the waterfall model an appropriate process model? Recognizes distinct activities Cheaper design before construction, but. . . ¡ too long a wait before hands on result ¡ Business requirements can change before system goes live Clear structure facilities multi-group dev, but. . . ¡ Lower level surprises ¡ Programmer design changes Actual processes are more complex ¡ numerous iterations among phases ¡ not purely top down ¡ decomposition into subsystems many variations of the waterfall model ¡ Prototyping, re-engineering, risk reduction

#2 Incremental development Chapter 2 Software Processes • • Prototypes Phases Agile Cycles Test Releases 46

Incremental development benefits The cost of accommodating changing customer requirements is reduced. (less analysis and doc) It is easier to get customer feedback on the development work that has been done. More rapid delivery and deployment of useful software to the customer is possible. Incremental development problems The process is not visible. System structure tends to degrade as new increments are added. Chapter 2 Software Processes 47

#3 Reuse-oriented software engineering Chapter 2 Software Processes 48

RISK Adverse #4 Boehm’s spiral model Chapter 2 Software Processes 49

Spiral model sectors Objective setting ¡ Specific objectives for the phase are identified. Risk assessment and reduction ¡ Risks are assessed and activities put in place to reduce the key risks. Development and validation ¡A development model for the system is chosen which can be any of the generic models. Planning ¡ The project is reviewed and the next phase of the spiral is planned. In practice – affects thought, but not used Chapter 2 Software Processes 50

#5: The Rational Unified Process A modern generic process derived from the work on the UML and associated process. Brings together aspects of the 3 generic process models discussed previously. Normally described from 3 perspectives ¡A dynamic perspective that shows phases over time; ¡ A static perspective that shows process activities; ¡ A practice perspective that suggests good practice. Chapter 2 Software Processes 51

Phases in the Rational Unified Process High Level Requirements Design / Architecture Detail Design, Code, test Chapter 2 Software Processes Deploy, Train 52

RUP iteration In-phase iteration ¡ Each phase is iterative with results developed incrementally. Cross-phase iteration ¡ As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally. Chapter 2 Software Processes 53

Static workflows in the Rational Unified Process Workflow Description Business modelling The business processes are modelled using business use cases. Requirements Actors who interact with the system are identified and use cases are developed to model the system requirements. Analysis and design A design model is created and documented using architectural models, component models, object models and sequence models. Implementation The components in the system are implemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process. Chapter 2 Software Processes 54

Static workflows in the Rational Unified Process Workflow Description Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation. Deployment A product release is created, distributed to users and installed in their workplace. Configuration and This supporting workflow managed changes to the system (see change management Chapter 25). Project management This supporting workflow manages the system development (see Chapters 22 and 23). Environment This workflow is concerned with making appropriate software tools available to the software development team. Chapter 2 Software Processes 55

RUP good practice Develop software iteratively ¡ customer Manage requirements ¡ priorities / deliver in increments document initial and changed requirements. Use component-based architectures ¡ make reusable when possible Visually model software using UML Verify software quality Control changes to software ¡ Change management for requirements ¡ Configuration management for code Chapter 2 Software Processes 56

Summary - Software Process Models Plan based – Waterfall Incremental – Agile Reuse COTS (commercial off the shelf) Boehm’s Spiral - Risk Rational Unified Process – UML iterative phases

Ethics

Software engineering ethics 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 but involves following a set of principles that are morally correct.

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 principles ACM / IEEE-CS Code of Ethics 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. Chapter 1 Introduction 62

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.

Summary Course Structure Why Software Engineering is important Software Process Activities Software Process Models ¡ Plan based – Waterfall ¡ Incremental – Agile ¡ Reuse COTS (commercial off the shelf) ¡ Boehm’s Spiral - Risk ¡ Rational Unified Process – UML iterative phases Code of Ethics