1 / 37

1. The Context of Software Engineering

1. The Context of Software Engineering. Definition of “Engineering”. The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice …... -- Accreditation Board for Engineering and Technology. Definition of “Engineering”.

swain
Télécharger la présentation

1. The Context of Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 1. The Context of Software Engineering

  2. Definition of “Engineering” The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice …... -- Accreditation Board for Engineering and Technology

  3. Definition of “Engineering” The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is appliedwith 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

  4. 2. The Activities of Software Engineering Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  5. Basic Activities of Software Engineering 1/2 • defining the software development process to be used • chapter 1 • managing the development project • introduced in chapter 2; also referenced in the remaining chapters • describing the intended software product • chapters 3 and 4 • designing the product • chapters 5 and 6 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  6. Basic Activities of Software Engineering 2/2 • implementing the product i.e. programming it • chapter 7 • testing the parts of the product • chapter 8 • integrating the parts and testing them as a whole • chapter 9 • maintaining the product • chapter 10 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

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

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

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

  11. 3. Process

  12. Set of activities carried out to produce an application Process(chapters 1 & 2) • Development sequence: • Waterfall • Iterative Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  13. Process(chapters 1 & 2) 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 • International Standards Organization • ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  14. 3. Project

  15. Project workflow people • Set of activities carried out to produce an application • OO: very useful paradigm Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

  17. 4. People5. Product

  18. Artifacts • Product-- the application and associated artifacts, including: • Requirements (chapters 3 & 4) • explain what product is meant to be • Software architecture (chapter 5) • Garland and Shaw's classification • Detailed design (chapter 6) Software Requirements Specification Design model Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  19. Artifacts • Product-- the application, • and associated artifacts, including: • Requirements (chapters 3 & 4) • explain what product is meant to be • Software architecture (chapter 5) • use Garlan and Shaw's classification • Detailed design (chapter 6) • use the language of Design Patterns • Implementation(chapter 7) • emphasize standards • employ selected formal methods. • Test artifacts(chapters 8 and 9) 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.

  20. 6. Quality

  21. Application must satisfy predetermined standards. • Methods to attain quality goals: • Inspection (introduced in chapter 1) • team-oriented process for ensuring quality • applied to all stages of the process. Quality Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  22. Application must satisfy predetermined quality level. • Methods to attain quality level: • Inspection (introduced in chapter 1) • team-oriented process for ensuring quality • applied to all stages of the process. • Formal methods(introduced in chapter 1) • mathematical techniques to convince ourselves and peers that our programs do what they are meant to do • applied selectively • Testing • at the unit (component) level (chapter 8) • at the whole application level (chapter 9) • Project control techniques(chapter 2) • predict costs and schedule • control artifacts (versions, scope etc.) Quality Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. 7. Student Team Project

  24. Decide Initial Team Issues One way to ... 0. Set the meeting agenda and time limits. (chapters 1 and 2 cover this is more detail) 1. Choose the team leader. 2. Decide how the team will communicate. See figure tbd. 3. Identify the customer. The party or parties who want this application. 4. Get an understanding of the project in general terms. Don’t be embarrassed if project seems too vague to you. Probe until you are comfortable. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  25. Set Team Expectations One way to ... 1. Get everyone’s commitment to taking required time • Define an expected average number of hours per week • If not forthcoming: Industrial: alert management Academic: inform instructor; implement written mutual evaluations • Gather dates of planned absences 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.

  26. 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 Ajax release 9. e-mail should be via BestMail release 4 -- if this is not possible, the e-mail should be verified as being compatible, especially for attachments. 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, www.xxx.yyy with automatic notification to every member. The “subject” format should be Attn. <name(s)>: subject matter. 6. Alternative mode of electronic communication: For 1-1 communication of very limited group interest, members will use e-mail 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.

  27. 8. Case Study Overview

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

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

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

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

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

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

  34. Homework

  35. Team exercises (Title: "Communication") For the following exercises, consider as a group how you will perform it, check the hints below, then carry out the assignment.  T1h Decide who your team leader(s) will be. Note that being team leader provides you with practice that you may otherwise be hard to get.   T2h Decide how your team will communicate, and test your communication methods. Specify your communication tools and methods. Be specific: you may change the specifics later. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  36. Team exercises (Title: "Communication") ctd. T2h Decide how your team will communicate, and test your communication methods. Specify your communication tools and methods. Be specific: you may change the specifics later. T3h Search the Web for the latest information on a topic determined by the instructor (e.g., the TSP). Note at least four of its basic goals and at least five of the techniques it uses. Post the references to the course forum or web site if there is one, and annotate your posting with the name of your group. State individual and/or group opinions of the topic or issue. Your team response should be 4-7 pages long.  Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  37. Team exercises (Title: "Communication") ctd. Evaluation criteria: a. Clarity (A = very clearly written, with all salient points explained and negligible redundancy) b. Specificity (A = specific procedures as to how the team will communicate under most conceivable circumstances) g. Soundness of your topic summary (A = very clear that the writer understands the goals of the Team Software Process; posting clearly organized) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

More Related