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

2. 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

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. 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

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

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

12. 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 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, 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 …

13. Why Study Software Engineering
ESaaS Mooc video
Introduction to Software Egineering

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

15. 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

16. 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

17. 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 -
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

18. 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.

19. 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.

20. 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

21. 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.

22. 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.

23. 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.

24. 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.

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

26. 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.

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

28. 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.

29. The most challenging part of any project
4. People
The most challenging part
of any project

30. 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

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

32. 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.

33. A software application must satisfy a predetermined level of quality

34. 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.

35. 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

36. 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

37. 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:

38. 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.

39. 7. Student Team Project

40. 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.

41. 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.

42. 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.

43. 8. Case Study Overview

44. 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.

45. 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.

46. 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 = 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.

47. 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.

48. 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.

49. 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.