Unhappy with today? Design tomorrow. CS361 Software Engineering I

Poverty

Reducing poverty with software

Addiction

Supporting counseling with software

Natural Disaster

Locating disaster victims with software

Pollution

Reducing energy consumption with software

Repression

Fomenting revolution with software

Engineering is… Solving real-world problems … … without making the world worse … … and without incurring excessive costs. Software engineering is doing all that by creating software.

Software is not enough— you also need people and context DatabaseWeb application Database server (Mysql?) PHP runtime environment (Zend?) Web server (Apache?) Operating system (Linux?) Hurricane survivors Friends and family System Boundary hardware (Linux?)

Where’s the system boundary? Some diagrams are more helpful than others! You’ll learn some good notations in this class.

What is the difference between good software and great software? The quality attributes of great software: Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reusability Interoperability

Great software contains the right features for the right data. Use cases = the activities a system supports e.g.: tweet a vote report, view delays on map Entities = the kinds of objects that are involved in use cases e.g.: tweets, user accounts, polling locations, maps Attributes = the properties of the entities e.g.: tweets have: timestamp, text, sender You can’t build a great system until you understand what it should do.

Software engineering is a team effort. Requirements Design Implementation Testing System Delivery Analyst Designer Programmer Tester Trainer

How do you create great software? Professionalism – Character – Teamwork – Planning – Risk management Technical skills – Design – Implementation – Quality control All of these are necessary. Not a single one is optional. All will be practiced in this course.

Course Objectives At the completion of the course, students will be able to... Select the most appropriate software process model to use in a particular situation Synthesize requirements for a realistic software system and write a requirements specification document Produce professional-quality software-related documents Model system requirements using one or more semi-formal notations such as UML, dataflow diagrams, entity-relationship diagrams, or state diagrams Design software systems at an architectural level and at lower levels, using one or more techniques, such as object-oriented design or agile methods, and express these designs in design specification documents Validate designs and adjust the specification or design as necessary Describe several methods of estimating the cost and developing a schedule for a programming project Participate effectively in a team environment Develop and articulate content knowledge and critical thinking in the discipline through frequent practice of informal and formal writing. Demonstrate knowledge/understanding of audience expectations, genres, and conventions appropriate to communicating in the discipline. Demonstrate the ability to compose a document of at least 2000 words through multiple aspects of writing, including brainstorming, drafting, using sources appropriately, and revising comprehensively after receiving feedback on a draft.

Course Objectives To train you in... process: a sequence of activities intended to design and produce software requirements: a description of what software should do and should be design: a description of something that could be created validation: making sure that you are headed the right direction notations: the rules for describing requirements, designs, and systems writing: expressing yourself in printed sentences cost and schedule: the amount of money and time expended on creating a system teamwork: people striving toward a common goal

Basic Course Information web.engr.oregonstate.edu/~cscaffid/courses/CS361_F11 Instructor: Prof. Chris Scaffidi Lectures: TR /9/12-3/16/12 GRAF 306 Office hours: Wed. 12-1pm in Kelley Engineering Center 3047 Teaching assistants: Alex Diede Optional book: Software Engineering, 4th ed. by Pfleeger & Atlee Homework: usually due electronically on Tuesdays before lecture Most homework will take your team a whole week to complete.

Course Outline 1.You each draft a vision… a system that you would like to see. 2.We get you organized into teams, 1 vision per team. 3.Each team does homeworks to design the envisioned system. 4.Each person does a midterm exam. 5.You each update your vision. 6.We get organized into new teams, 1 vision per team. 7.Each team does homeworks to create the envisioned system. 8.Each team does a final presentation on their system. 9.Each person does a final exam.

Teamwork Project homeworks will be done in teams. Usually, all students in a team will receive the same grade on each homework. I will assign you to teams based on which of your classmates’ vision statements are most interesting to you. Any team can ask me to fire a teammate on or before the day that the team’s first homework is due. You need to have a good reason for firing teammates. I must approve all firings. Fired students may band together into a new team. See regulations on the course web site.

Grading 7 team homeworks – 6% each 1 vision statement – 8% 1 midterm exam – 25% 1 final exam – 25% See course website for additional information on grading, academic integrity, and other policies. = slide has a good chance of being on the midterm or final exams.

Vision statement A description of a system that you think could change the world for the better Schedule – Upload your first draft BY THURSDAY – Upload your next draft BY TUESDAY – Upload your final draft BY Mar 1 10 extra credit points if your vision statement is chosen by popular vote for use by a team during the first or second half of this term

Where do you go from here? Read the syllabus on the course web site web.engr.oregonstate.edu/~cscaffid/courses/CS361_W12/ Upload your Vision Statement first draft You’ll vote on visions this weekend so that I can put you in teams.