Comp3663 Software Engineering II 2001 Comp3663 Software Engineering II Daniel L. Silver, Ph.D. Daniel L. Silver

Outline Who am I? Who are you? Objectives of the course 2001 Outline Who am I? Who are you? Objectives of the course Review of the course homepage Stuff you need to have and do 14-Nov-18 Daniel L. Silver Daniel L. Silver

Who am I? Danny Silver, BSc(Acadia), MSc, PhD(UWO) 2001 Who am I? Danny Silver, BSc(Acadia), MSc, PhD(UWO) Background/Experience: 2 years N.S. Government (Systems Programmer) 9 years MTT – MIS (Prog.- Project Manager/Advisor) 3 years SHL System House (Technical Architect, Project Manager, Branch Management) 3 years Dalhousie (Assoc.Chair, Business Informatics) 16 years Acadia (former Director) 20 years CogNova Technologies (Private Consulting) The Bad News and the Good News 14-Nov-18 Daniel L. Silver Daniel L. Silver

Who are you? Your name Something unique about yourself 2001 Who are you? Your name Something unique about yourself How you hope to benefit from this course Individual survey 14-Nov-18 Daniel L. Silver Daniel L. Silver

Things you hope to learn from the course 2001 Things you hope to learn from the course 14-Nov-18 Daniel L. Silver Daniel L. Silver

Objectives of the Course 2001 Objectives of the Course To introduce the major theories and methodologies of large project software engineering – project management, system specification and design, development, testing, implementation, and documentation To gain further knowledge of activities such as project meetings and minute taking, project planning and tracking, status reporting, product and process evaluation and individual and group assessment. To provide an opportunity to apply this knowledge in a group project environment working on medium sized software application 14-Nov-18 Daniel L. Silver Daniel L. Silver

Objectives of the Course 2001 Objectives of the Course Project work will constitute a major portion of the course and provide an opportunity to experience the challenges and rewards of working in a team Each participant will participate in various roles within their project team (leadership, design, coding, documentation, etc.) The course will be challenging on an interpersonal level and time consuming because of this challenge Personal productivity and project management will remain important aspects throughout the course 14-Nov-18 Daniel L. Silver Daniel L. Silver

Personal/Project Management 2001 Personal/Project Management PSP - Personal Software Process TSP – Team Software Process Weekly Summary Sheet Please review the Lessons Learned from prior classes regarding the project. 14-Nov-18 Daniel L. Silver Daniel L. Silver

Stuff you will need to have 2001 Stuff you will need to have Text book by Braude Laptop / Website access Favourite Language and Development Environment Hand-outs from class 14-Nov-18 Daniel L. Silver Daniel L. Silver

Review the course homepage 2001 Review the course homepage 14-Nov-18 Daniel L. Silver Daniel L. Silver

THE END danny.silver@acadiau.ca 2001 THE END danny.silver@acadiau.ca Daniel L. Silver

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://www5.in.tum.de/~huckle/bugse.html

Why Study Software Engineering ESaaS Mooc video Introduction to Software Egineering

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

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 real-world 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 [Ja1]; 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 (by whom it is done) Process (the manner in which it is done) * * Symbology from [Ja1]; 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 (by whom it is done) Process (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 (by whom it is done) Process (the manner in which it is done) * Project (the doing of it) Product (the application artifacts) * Symbology from [Ja1]; explained in chapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

Set of activities carried out to produce an application Process Set of activities carried out to produce an application Development sequence: Waterfall Iterative Process frameworks: Personal Software ProcessSM Team Software ProcessSM Capability Maturity ModelSM -- 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.

Implementation of processes to to produce the desired artifacts Project Implementation of processes to to produce the desired artifacts

Set of activities required 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.

The most challenging part of any project 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

The software application and associated project artifacts 5. Product The software application and associated project artifacts

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

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 PUBLIC - Software engineers shall act consistently with the public interest. 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. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. JUDGMENT- Software engineers shall maintain integrity and independence in their professional judgment. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 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 One way to ... 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.

1. Get everyone’s commitment to taking required time Set Team Expectations One way to ... 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 One way to ... 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 6pm 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 Current life points: 100.0 Choose the quality you wish to set 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.

User Interface for Setting Quality Values Shawn Current life points: 100.0 Image Choose the quality you wish to set 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 OK Graphics reproduced with permission from Corel. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Engage Foreign Character Use Case Details of use case Encounter 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. Initialize player Engage foreign character Actor (agency external to the application) Name of use case . . . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

FrameWork / 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.

FrameWork / Application Dependency Characters GameEnvironment RolePlayingGame Role-playing game layer (framework) «uses» Encounter video game layer EncounterGame «uses»* «uses» EncounterCast EncounterGame EncounterCharacters EncounterEnvironment * by member classes implemen- ting framework interfaces EncounterEnvironment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.