Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Week 1 Introduction, Writing a Program, Building a System Software Engineering Fall Term 2015 Marymount University School of Business Administration.

Similar presentations


Presentation on theme: "1 Week 1 Introduction, Writing a Program, Building a System Software Engineering Fall Term 2015 Marymount University School of Business Administration."— Presentation transcript:

1 1 Week 1 Introduction, Writing a Program, Building a System Software Engineering Fall Term 2015 Marymount University School of Business Administration Professor Suydam

2

3 3

4 4

5 5 Form 3-person teams Create “distinguished” name Organize for team projects (Case Studies)

6 6

7 7 IT210 is designated a Writing Intensive Course. Upon successful completion of this course, students will be expected to: a. Produce written work appropriate for the information technology profession through a process that involves drafting and revision based upon feedback; b. Produce focused and coherent documents that address business audiences, move effectively between generalizations and details, make honest use of sources, and engage in complex ideas without distortion; c. Draft documents that show careful attention to fluent sentence structure, grammatical correctness, and proper technical documentation; and d. Take the subject of documentation in the information technology field, analyze appropriate primary and secondary sources materials and support a focused approach in a clear, persuasive, and coherent document. e. The Marymount University Center for Teaching and Learning, Writing Outcomes for WI Course is at the following URL: http://commons.marymount.edu/muctl/wi-resources/wi-objectives/

8 8

9 9 Go through Class Website and know how to navigate Get textbook and read chapters 1 & 2 Get with Teammates – make plan for how you will meet during semester Decide: Team Name, Case Study (CS) Project, CS Project Name

10 10

11 11 We all “start” by learning how to code in some programming language. With a small, hypothetical, and fairly well defined problem Usually the code is within one module We then learn that the program usually does not work on the first try, second try ------ may be even 5 th or 6 th try! We learn about “testing” the program We learn about re-reading and re-thinking the (problem) requirements more carefully --- then find that we may not have all the answers We learn about tracing and “debugging” the program Then ---- somehow magically ---- we decide that it’s “good enough !” Perhaps Not In This Order

12 12 1) Understand the problem – requirements Functionalities Non-functionalities: performance, security, modifiability, marketability, etc. 2) Perform Some Design --- based on requirements Organizing the functionalities in some sequence; possibly using some diagrams Focus on input/output ( data, formats, organization) Think about some constraints (non-functionalities) such as speed, UI looks, programming language, dependencies, etc. any specific algorithm and improvements on sequence of functionalities.

13 13 3) Code/Implement – Turning the design into actual code -- Depending on how much design is completed, one may either directly engage in conversion to code (language dependent) or do some more designing. a) Converting input/output to specific UI Interface or I/O format b) Sequencing the processing in the desired order c) Ensuring and converting the processing “algorithm” correctly to the target language construct. d) figure out how to use language library (properly)

14 14 4) Validate/Test the program – check the program results (via output) with some predetermined set of inputs. The pre-determined inputs are “test cases” and requires some thinking. If the results do not match what is expected then: “Debug” Fix Retest ---- revalidate Stop when all test cases produce the expected results.

15 Problem Definition/ Understanding Solution Design Solution Implementation/ coding Solution Testing Problem Definition/ Understanding Solution Design Solution Implementation/ Coding Solution Testing “Imagined” – Ideal Situation “Actual” - Happening

16 16 How long (elapsed time) did it take to complete the work? How much effort (total person hours) is expended to do the work? Does the solution solve the complete problem? How “good” is the work – (code, design, documentation, testing, etc.)? based on ?

17 17

18 18

19 19

20 20 The most important rule is to be consistent—especially in your choice of names, capitalization, and programming conventions. Choose names carefully. In addition to being consistent in naming, try to make sure names for functions and variables are descriptive. Test before using a function or method. Make sure that it works. Know thy standard library. In most modern programming languages, the standard library will implement many common functions, usually including sorting and collections of data, database access, utilities for web development, networking, and much more.

21 21

22 22

23 23

24 24

25 25 Prepare for class 9/10

26 26


Download ppt "1 Week 1 Introduction, Writing a Program, Building a System Software Engineering Fall Term 2015 Marymount University School of Business Administration."

Similar presentations


Ads by Google