Introduction to Software Engineering Why Study Software Engineering

Introduction to Software Engineering

Why Study Software Engineering • An air traffic controller, relying on information from his computer console, directs two Boeing 747's onto intersecting paths. The jets collide and burst into flame, and all aboard perish. -- Washington Post • "Software Gone Awry", Scientific American, October 1996 --Investigators appointed by the European Space Agency reported in July that a software bug brought down the new $8 -billion Ariane 5 rocket. • A hospital minicomputer, monitoring a patient recovering from surgery, fails to alert hospital staff that the patient is having a stroke. The patient dies. -- Washington Post • "Computer bug bites Alberta exchange", Calgary Herald, October 24, 1996 -- The Alberta Stock Exchange crashed at 7: 38 a. m. Wednesday, brought down by a glitch in its new, fully computerized trading system. • A company dicovers that its computer has mangled valuable and sensitive information beyond recovery. The loss gravely weakens the company's market position. -- Washington Post • Also see … http: //www 5. in. tum. de/~huckle/bugse. html

Why Study Software Engineering • ESaa. S Mooc video • Introduction to Software Egineering

1. The Context of Software Engineering Science Engineering Computer Science Software Engineering

What is “Engineering” The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind -- Accreditation Board for Engineering and Technology, 1996

What is Software Engineering? • Plan and Document Perspective: – Software engineering (SE) is "the establishment and use of sound engineering principles in order to obtain, economically, software that is reliable and works efficiently on real machines" [Fritz Bauer at the seminal conference on SE, 1969] – SE is about applying computer science to realworld problems

What is Software Engineering? • Agile / Iterative Perspective: – – Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan [The Agile Manifesto - http: //agilemanifesto. org] • While there is value in the items on the right, we value the items on the left more. • SE is as much craft as it is sceince/engineering

2. Activities of Software Engineering · defining the software development process to be used (ch. 1) · managing the development project (ch. 2 and throughput) · describing the intended software product (ch. 3, 4) · designing the product (ch. 5, 6) · implementing (programming) the product (ch. 7) · testing the parts of the product (ch. 8) · integrating the parts and testing them as a whole (ch. 9) · maintaining the product (ch. 10) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The One Week Project Sat: Martin asks Nick about developing a web-based Time Management Tool for project team members. Sun: Nick develops business case (value) and preliminary plan to sell to Martin – architecture by Tues, then go/no-go Mon: Nick develops problem statement, vision of system, risk list, project plan, sense of value and cost. Tue: Nick develops prototype in AM, meets with Martin for lunch to review all artifacts and update requiremenst. Go/No-go decision. Develop use cases and test in PM. Wed: Nick designs, codes and tests iteration 1 and 2. User Dan provides feedback on iteration 1. New req. added Thur: Nick designs, codes and tests iteration 3. Version control tool and bug list used to manage growing code. New req. added. Capacity tests. Fri: Beta version installed on some of Martin’s team computers in AM. Users find bugs. New release created in PM. First Alpha version created on CD in evening.

Highlights of the Project • Fully understand users needs, and convey developer needs (greatest ask of user? ) • Develop business case • Assess risks and mitigate: – Technical – Business – What did Nick use to mitigate risk? • • • Develop core architecture Develop test cases that matched requirements Stay on top of the job – discipline, document Use version control to backup software changes Write important stuff down and share it

The Four “P’s” of Software Engineering * People (by whom it is done) * Symbology from [Ja 1]; explained in chapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering * People Process (by whom it is done) (the manner in which it is done) * Symbology from [Ja 1]; explained in chapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering * People Process (by whom it is done) (the manner in which it is done) Project (the doing of it) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Four “P’s” of Software Engineering * People Process (by whom it is done) (the manner in which it is done) Project Product (the doing of it) (the application artifacts) * Symbology from [Ja 1]; explained in chapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Process Set of activities carried out to produce one or more artifacts

Process Set of activities carried out to produce an application Development sequence: Waterfall Iterative Process frameworks: Personal Software Process. SM Team Software Process. SM Capability Maturity Model. SM -- for organizations Standards: Institute of Electrical and Electronic Engineers (IEEE) International Standards Organization (ISO) Canadian Information Processing Society (CIPS) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

Project Implementation of processes to to produce the desired artifacts

Project people flow of work Set of activities required to to produce the desired artifacts • Object Orientation: very useful paradigm • Unified Modeling Language: design notation • Legacy systems: common starting point replacement of, enhancement or addition to existing system Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. People The most challenging part of any project

People • A small software project can be done by one person • Medium/large software projects require a team • Interactions between people necessary, but difficult • Managers, analysts, programmers, testers, users, customers • We will learn certain skills • • • Project Management Effective Meetings Presentations Pair-programming Technical documentation Technical Reviews • Your project work will provide practical hand-on experience

5. Product The software application and associated project artifacts

Product -- the application and Artifacts associated artifacts, including: • Requirements Specifies what the product must do Software Requirements Specification • Software architecture Single user, network centric, database? • Detailed design Describes how the product will work Design model • Implementation Emphasizes standards Source & Employs selected coding methods object code • Test artifacts Test procedures; test cases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

6. Quality A software application must satisfy a predetermined level of quality

Methods to attain desired level of quality • Inspection • team-oriented process for ensuring quality • applied to all stages of the process • Paired programming • creates more readable, better commented code • Formal methods • mathematical checks to ensure programs do what they are meant to do • Testing • at the unit (component) level, integration level • at the whole application level • Project control techniques • predict costs and schedule • control artifacts (versions, scope etc. • Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Professional and Ethical responsibility • SE involves wider responsibilities than simply the application of technical skills • SEs must behave in an honest and ethically responsible way if they are to be respected as professionals • Ethical behaviour should be > legal responsibility: – Confidentiality - respect the confidentiality and intellectual property of their employers or clients – Competence - do not misrepresent level of competence or accept work beyond ability to deliver

Ethical dilemmas you may encounter • 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 components for military weapons or biogenetic systems

ACM/IEEE Code of Ethics • Eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. • Preamble – Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

ACM/IEEE Code of ethics - principles 1. PUBLIC - Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. JUDGMENT- Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

7. Student Team Project

Decide Initial Team Issues 0. Set the meeting agenda and time limits. (see ch. 1, 2) 1. Choose the team leader. 2. Decide how the team will communicate. 3. Identify the customer 4. Get an understanding of the project in general terms - don’t be embarrassed; if project seems too vague, probe until you are comfortable. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Set Team Expectations 1. Get everyone’s commitment to taking required time – Define an expected average number of hours per week – Gather dates of planned absences – If not forthcoming - alert management, inform instructor; implement written mutual evaluations 2. Choose team emphasis: accomplishment / learning – Accomplishment (capable product): get a good mix of leadership, technical, writing, customer relations – Learning: sacrifice accomplishment by allowing members to experience new activities. – Understand manager’s / instructor’s emphasis. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Specify How the Team Will Communicate 1. General policy: if in doubt, communicate. Redundancy is OK! 2. Meeting: The team will meet each Wednesday from 8 a. m. to 10 a. m. in room 671, unless notified of a change. 3. Meeting alternative: Team members should keep Mondays 4 to 6 pm open in case an additional meeting is required. 4. Standards: The word processing used will be MS Word. 5. Preferred mode of electronic communication: Unless a communication is of very limited interest to the group, it should be posted to the group site, axe. acadiau. ca with notification to all members. 6. Alternative mode of electronic communication: For 1 -1 communication of very limited group interest, members will use MSN and/or telephone. 7. Acknowledgement: Team members should acknowledge all electronic communication specifically targeted to them, whether asked to acknowledge or not. Senders should follow up on all significant communication that is not acknowledged. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. Case Study Overview

Sample Encounter Screen kitchen COURTYARD living room dressing room Get status Set qualities Graphics reproduced with permission from Corel. End game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User Interface for Setting Quality Values Shawn Choose the quality you wish to set Current life points: 100. 0 Choose the value of the quality selected 16. 3 image Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Shawn Choose the quality you wish to set User Interface for Setting Quality Values Current life points: 100. 0 Image Choose the value of the quality selected 16. 3 Explanation The values of the qualities not specifically chosen remain in the same proportion to each other. Values less than 1. 0 are counted as zero. E. g. , before: strength = 10. 0, endurance = 60. 0, intelligence = 30. 0, patience = 0. 0 (current life points 10. 0 + 60. 0 + 30. 0 + 0 = 100. 0) change: strength from 10. 0 to 20. 0 after: strength = 20, endurance = 53. 33, intelligence = 26. 66 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. OK Graphics reproduced with permission from Corel.

Engage Foreign Character Use Case Details of use case Encounter Initialize player Actor (agency external to the applicati on) Engage foreign character Name of use case . . 1. System displays the foreign character in the same area as the player’s. 2. System exchanges data between the two characters. 3. System displays the results of the engagement in a message window. 4. Player dismisses window. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Frame. Work / Application Dependency Role-playing game layer Encounter video game layer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Frame. Work / Application Dependency Characters Game. Environment Role. Playing. Game «uses» Role-playing game layer (framework) Encounter video game layer «uses» * «uses» Encounter. Cast Encounter. Characters * by member classes implementing framework interfaces Encounter. Game Encounter. Environment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.