(1) ICS 314: Software Engineering Philip Johnson Collaborative Software Development Laboratory...

(1)

ICS 314:Software Engineering

Philip Johnson

Collaborative Software Development Laboratory

Information and Computer Sciences

University of Hawaii

Honolulu HI 96822

(2)

Contact Information Email:• johnson@hawaii.edu

Website:• http://ics314f13.wordpress.com/

Office/Phone:•POST 307A (CSDL Office)• 956-3489

Office Hours:•MW 12:30 – 1:30, or whenever my door is open

(3)

My SE background 1970’s: •Business applications programming (COBOL)

1980’s:•Real-time data communication software (Assembler)•EEC-IV compiler validation for Ford (Pascal-like)•AI blackboard technology (Lisp)• Type inferencing system (Lisp)

1990’s:•Collaborative software infrastructure (Lisp, C++)•Software metrics technology (Java)

2000’s:•Automated software measurement and analysis (Java)•Software Engineering for High Performance Computing Systems•Smart Grid/Smart Consumer applications (Java, Javascript)

2010's:•Energy, sustainability, gamification research (kukuicup.org)

(4)

Goals of the class

Learn how to build high quality, large scale software systems. •By “growing” a high quality, small scale system into a

large one.•By pursuing the open source “prime directives”•By using tools whenever possible to assess various

“quality” attributes.

Develop a “professional persona”•Portfolio, Blog, TechHui, LinkedIn.•Support your entry into “real world”.•Create a positive “image” for potential employers.

(5)

What is “Quality”?

Attributes of a high quality software system:•Easy for users to:

-adopt and use to achieve their goals•Easy for administrators to:

-install, upgrade, debug, obtain help•Easy for developers to:

-read, enhance, build, test, debug, optimize

This is (relatively) easy... for a small scale system.

This class is about maintaining “easiness” as the:• system becomes large (i.e. 100,000 -> 1M+ LOC)• development group becomes large (5 -> 10 -> 50+ devs)

(6)

Three Prime Directives of Open Source Software

The system accomplishes at least one useful task.

A new user can successfully install and use the system.

A new developer can successfully understand and enhance the system.

(7)

Prime Directive #1 The system successfully accomplishes at least one useful task.•No complex system is ever “complete”.• Instead:

-QUICKLY implement a core set of functions -Extend and improve system forever based upon user feedback, changing environment, etc.

•PD#1 is facilitated by standards for:-User interface-User documentation-Interaction with other systems

Achieving and maintaining PD#1 requires regular feedback from external end-users.

(8)

Prime Directive #2

A new user can successfully install and use the system.•The documentation is sufficient to enable non-developers of the software to download, install, and benefit from the “useful task” implemented by the software.

•PD#2 is facilitated by standards for:-Packaging the software into a distribution.-Installation procedures

Achieving and maintaining PD#2 requires regular feedback from external installers.

(9)

Prime Directive #3 A new developer can successfully understand and enhance the system.•Successful open source software “takes on a life of its own” and does not require continuing participation from the original developer (Linux, Emacs, Java, SendMail, etc.)

•PD#3 is facilitated by standards for:-Coding (coding standards)-Design (design patterns)-Packaging (Make, Ant)-Unit tests (coverage, Unit tests)-Documentation (JavaDoc, etc.)

Achieving and maintaining PD#3 requires regular feedback from external developers.

(10)

Standards and feedback A consistent theme across all three PDs is the importance of standards and feedback:

Standards:•Allow higher quality communication to occur by removing low-level obstacles including:-Idiosyncratic coding, package structure, user interface, etc.

-A reasonable standard observed by all participants is better than individual, differing, more highly optimized approaches.

Feedback:•As the developer, you cannot put yourselves in the shoes of outside users and developers. To achieve and maintain the PDs, you must seek outside feedback early and often.

(11)

Standards We will employ many standards in this class in order to improve the quality of communication and facilitate achieving the three PDs:•Coding standards•Package structuring standards•Engineering log standards•Review process standards•Tool standards

(12)

Feedback

Feedback in this class comes from the following sources:•Your group members (for group projects)•Other class members (via code/design review)•Me•ICS Software Engineering mailing list•Tools (Checkstyle, PMD, FindBugs, etc.)•Outside community (mailing lists, forums, potential users, etc.)

(13)

Texts Thinking in Java, 4th edition•Good intro to the Java language.•Optional if you are skilled in Java• $25 ebook

Elements of Java Style• Best guide to best practices in code

formatting and documentation.• $10 ebook

Play for Java, early access edition•Only book on Play Framework• "early access" -> still some bugs• $40 ebook

(14)

Course prerequisites Java programming background•At least one year/one thousand lines of code.•You must have taken and passed ICS 211 (or equivalent) PRIOR

to this course.

Development environment:•Unix, Macintosh OS/X, Windows XP-Pro or 7 are OK.•Windows 95/98/ME/XPHome/Vista are not OK!!!• Fast network connection• ICS Lab and TA machines not viable for this class. • ICS Department has site license for XP-Pro/7; get it!

Lots and lots of time:•Software development takes a lot of hours.•What you put in determines what you get out. •Not everyone has the time, energy, or interest to become skilled

at software engineering.

(15)

Personal computational resources What you need:•A laptop with: >=2Ghz processor, >=1 GB RAM, >= 10GB free space, and wireless access.•Recommended: 15” screen or better.•Example: Dell, $500

This class involves a large amount of in-class programming; if you do not have a “developer level” laptop, you can not take advantage of those experiences.

“Netbooks” are not “developer level” laptops.•Underpowered (tools take too long to run)•Screen size too small

(16)

Grading Tentative grading scheme:•30%: Quizzes•20%: Final•50%: Programming assignments and homework

The weights and assignments may change.

Guarantees:•90-100% guarantees an A•80-89% guarantees a B•70-79% guarantees a C

(17)

Lectures and Labs Most lectures will be made available online as screencasts.

Class time will be dedicated to “labs” in which you do software development, either alone or in small groups. Attendence is mandatory!

You are responsible for listening to the lectures before the class period associated with the topic.

(18)

Quicky Quizzes

Each week, I will release the modules to be covered during the following week.

Each Monday, I will have at least one short, in-class, CLOSED BOOK/NOTES quiz on the current module.

Goal of quizzes:•Provide incentive for you to keep up with readings. •Ensure that you have assimilated the material to some extent. •Provide me with feedback on how the class is doing.

(19)

Engineering Log Software Engineering is a writing intensive discipline.

To help you acquire proficiency, you will create and maintain an engineering log in WordPress.

This will provide practice in writing technical prose for public use, and also enable you to create an archival record of your growth and experiences in software engineering.

(20)

Professional Persona A goal of this class is to help you develop your “professional persona” via:•Your online engineering log.•Your professional portfolio.•The open source code you authored.•Your participation in professional social networking sites (TechHui, LinkedIn)

Your professional persona:•is distinct from your “personal” persona (FaceBook, MySpace, etc.)•will help/hurt your job opportunities•is a career-long project.

(21)

Collaboration vs. Cheating Collaboration:• Talking with classmates about the most appropriate design for a

system.•Helping a classmate debug an error by reading their code and

suggesting diagnosis experiments.•Reusing open source code from the Net with attribution

Cheating:• Taking a copy of someone else’s code (either classmates or

from the net) and submitting it as your own (perhaps after minor rewriting to disguise the similarity.)

Cheating destroys the learning environment. If I catch you, you get an automatic F for the course.

If you are not sure if an activity constitutes collaboration or cheating, ASK ME!

(22)

Lessons Learned By the end of the semester, many students show insights!

Here are some examples:

(23)

Start early•If you start early then you should have more time to develop your project. You can allocate a portion of this time to explore different ways of doing things.

•Although I hate to be obvious, waiting till the last minute to code is not a very good idea. Considering the level of coding required for ICS SE, coding SHOULD be continuous at short intervals from day to day. It's hard. I know.

(24)

Testing actually helps•Unit testing helps a lot from the middle to the end of the development cycle. Initially, tests take extra time to create but it does pay off…

•JUnit is your friend. JUnit is the main tool to develop a set of tests which will ensure you have software that works the way you expect it to. Unit tests are what real Software Engineers who are serious about making high quality software use.

(25)

Read code•I've been able to learn much more about java, and programming concepts from reading code, than I have from writing java. 

•Code examples are your best friends. Nothing will explain to you how to do something as well as a good example can. Learn from the experience of others by reading what they've done.

(26)

Follow the standards

•You will not be the only person examining your code. For this reason, it's a good idea to practice programming following the Java programming style conventions. This improves readability and prevents you from having to go back and change everything later so someone else can understand what you have written.

(27)

Suspend your disbelief•Even though the things learned in class seem like a bunch of extra stuff that will just take up your time and not accomplish anything useful, once you start using all of the things you learn in class it makes it easy to create high quality software. Basically do it now, you'll be happy you did later.

•Take advantage of your resident expert Dr. Johnson. Try not to argue with him because believe it or not, he does know what the #@&%! he's talking about. It will make your life in ICS SE so much easier.

(28)

Best case scenario•Take advantage of the valuable resource that is Dr. Johnson.  Prior to enrolling in ICS SE with Dr. Johnson, I was very confused about what I was doing in ICS and sometimes lacked motivation. After one month in ICS SE, I was more confident and possessed a greater drive to learn than I ever had previously.  He may push you and sometimes require a lot out of you, but believe you me, it is well worth it.

(29)

Worst Case Scenario•Taking class from this professor is not worth the time and money as you could just might as well research software engineering on google and read the book and study on your own and come off learning more than he ever teaches - if he even actually teaches is questionable.

(30)

Course Process Use the Calendar page to find out when modules and assignments are due.

You are responsible for having studied all of the resources associated with a module as of the day it is listed in the calendar. If a module is listed on Monday, then there could be a QQ on that module on that Monday.

(31)

What to do now Look through the website.

Start work on the initial modules.

Have fun!