05 September 2006Kaiser: COMS W4156 Fall 20061 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]

05 September 2006 Kaiser: COMS W4156 Fall 2006 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://york.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



What is Software Engineering?

• Treating computers (including hardware, data structures, algorithms, computations, programming languages, compilers and interpreters, operating systems, databases, networks, graphics, user interface paradigms and devices, etc.) as problem-solving tools – To design and implement solutions to problems – To solve any problem, computers must run some appropriate

software that exploits and integrates the resources above

• Stakeholders working together as a team – including customers, users, administrators, technical writers and product managers as well as designers, programmers and testers


Why Study Software Engineering?

• Writing a program is easy• Developing a software product is hard• Software Engineering aims at supporting the

development of high-quality software products– High-quality software products are robust, efficient

and effective– High-quality software products are easier to

understand, modify, and compose with other high-quality software products

• To attain high-quality software, software engineers are skilled professionals who follow defined processes and “best practices”


What do Software Engineers Do?

• Newly hired software engineers typically assigned to maintain (or test) someone else’s code

• Maintenance: Everything after initial deployment– When was the last time you used a commercial or open source

program labeled “Version 1.0”?– 50-90+% of total lifecycle costs

• Categories of maintenance– Corrective - reactive modification to correct discovered problems– Adaptive - modification to keep it usable in a changed or

changing environment– Perfective - improve performance or maintainability– Preventive - modification to detect and correct latent faults

• However, 4156 will focus primarily on development, for practical reasons


Who am I?

• Gail Kaiser• [email protected] • Professor at Columbia for >20 years (!)• BS from MIT, MS and PhD from CMU• Worked summers and/or consulted for startups, defense

contractors, industry research labs, Software Engineering Institute, Educational Testing Service, Center for Computational Learning Systems

• Research in self-managing systems ("autonomic computing"), software testing, publish/subscribe event systems, computer and network security, applied AI, Web technologies, collaborative work, information management, distributed systems, and software development environments and tools

mailto:[email protected]?subject=4156


Who is the TA?

• Mr. Anurag Chakravarti

• [email protected]

• 2nd year MS

• Two years professional experience in SIP-based networking systems

mailto:[email protected]?subject=4156


Who are you?

• Seniors and graduate students in Computer Science, Computer Engineering, Biomedical Informatics, maybe others

• Sincerely interested in learning to apply Software Engineering methodologies and technologies – not just programming skills - to building and maintaining useful and usable software products


Textbooks

• Clemens Szyperski, Component Software: Beyond Object Oriented Programming, 2nd edition, Addison-Wesley, ISBN 0201745720

• Ron Patton, Software Testing, 2nd edition, Sams Publishing, ISBN 0672327988

• Ordered for this class through the Columbia University Bookstore

http://columbia.bkstore.com/

http://columbia.bkstore.com/


Assignments

• Most course work revolves around a team project • Students work primarily in pairs (2 people)• Grouped into 2-pair teams (4 people)• Each team will build a very small software system• 2 rapid iterations of project - each 3-4 weeks long• Major system functionality should be (more or less)

operational by the end of the 1st iteration• 2nd iteration will focus on quality assurance issues


Pairs and Teams

• Pairs ideally self-chosen – find a partner• Meet someone in class or advertise on the

4156 discussion forum on CourseWorks (http://courseworks.columbia.edu)

• 2 pairs may request each other for a team• Unattached individuals and pairs will be

assigned by the teaching staff• Each team will submit a proposal for the

very small system they want to build

http://courseworks.columbia.edu/


Computer Accounts

You may use any account you like, provided you can

1. Access the class website and CourseWorks

2. Submit written assignments in plain text, MS Word or Adobe PDF

3. AND last but not least…


Do the Team Project AS A TEAM

1. Develop and test your project code together with your programming pair partner

2. Integrate together with your team’s other pair

3. Demonstrate your project to the teaching staff

PLEASE use same programming language, operating system platform, programming environments and tools !!!


Exams

• Midterm and Final "Individual Assessments" • Take-home assignments that must be completed

by each student working individually• Demonstrate your understanding of software

engineering principles and how they apply to your team project

• Evaluate your own, your partner’s and your team’s work on the project thus far

• No other exams


Final Grade Breakdown

• 50% Team Project– 2 iterations at 25% each

• 35% Individual Assessments – 15% midterm– 20% final

• 15% Individual Development Assignments – A few small homeworks to develop and demonstrate

proficiency on component-based technologies– To acquire skills to be used in the team project


Frequently Asked Questions

• Do I have to join a pair/team?

YES!• Can I do the project alone?

NO!


Course Outline

1. Component-based software development– Component models and frameworks

2. Quality assurance– Code review, unit and integration testing

3. Other software engineering topics– Pair programming, requirements, software

process, refactoring, UML, ???


Pair Programming Overview

• Two programmers work side-by-side at one computer

• Continuously collaborate on same design, algorithm, code, test, etc.

• Continuous informal review


What about productivity?

• Demonstrated to improve productivity and quality of software products– Two programmers work together nearly twice as fast and

think of more solutions to a problem as two working alone– While attaining higher defect prevention and defect

removal

• One well-known empirical study (by Laurie Williams)– 15% lower overall productivity– But 50% fewer bugs (85% tests passed vs. 70%)– http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftw

are.PDF

http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF

http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF


All I Really Need to Know I Learned in Kindergarten : Uncommon Thoughts on Common Things

Robert Fulghum, 1988


All I Really Need to Know about Pair Programming I Learned in

Kindergarten. Laurie Williams and Robert R. Kessler.

Communications of the ACM, 43(5):108-114, May 2000.

http://collaboration.csc.ncsu.edu/laurie/Papers/Kindergarten.PDF




Share everything

• Two programmers are assigned to jointly produce one artifact

• One person typing or writing, the other continuously reviewing

• Both equal participants

• Both partners own everything


Play fair

• One person “drives” while the other continuously reviews

• Important to take turns “driving”, even if one programmer much more experienced than other

• Observer is active and engaged, not passive

• Continuous analysis, design and code reviews


Don’t hit your partner

• But make sure your partner stays focused and on-task

• Less time wasted (reading email, IMing, surfing web, etc.) than when working alone, since partner awaiting continuous contribution and input

• Each partner expects the other to follow prescribed development practices


Put things back where they belong• Put negative thoughts in the trash can• Very difficult to work with someone with great

insecurity or anxiety about their programming skills• Should view pair programming as an opportunity

to improve skills by watching and obtaining feedback

• Also difficult to work with big egos• No one is infallible and above the input of another


Clean up your mess

• Many obvious but unnoticed defects become noticed by another person watching over your shoulder

• Defects removed without the animosity that might develop during a formal inspection meeting


Don’t take things too seriously

• Ego-less programming

• Don’t be defensive with receiving criticism

• But don’t always just agree with your partner

• Initial adjustment period to pair programming in general and partner in particular


Say you’re sorry when you hurt somebody while moving furniture

• Appropriate workspace layout critical to success

• Slide the keyboard, don’t move the chairs

• Effective communication, within pairs and among pairs, is paramount

• Programmers need to see each other, ask each other questions, and make decisions on things such as integration issues


Wash your hands of skepticism before you start

• Partner buy-in critical to success

• A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts


Flush

• When pair programmers work on something independently, need to throw away and then rewrite jointly

• Or at least review jointly – but more likely then to still have defects


Warm cookies and cold milk are good for you

• Pair programming can be very intense and mentally exhausting

• Periodically take a break


Live a balanced life – learn some and think some and draw and paint and sign and dance and play and

work every day some

• Communicate with others on a regular basis• Most programmers would probably say they

preferred to work alone in a place where they wouldn’t be disturbed by other people

• But informal discussions allow for effective idea exchange and efficient transfer of information


Take a break from working together every afternoon

• Might do experimental prototyping, tough deep concentration problems, and logical thinking alone

• Simple, well-defined, rote coding more efficiently done alone and then reviewed with a partner


When you go out into the world, watch out for traffic, hold hands and

stick together

• No competition between the paired programmers

• Both work for a singular purpose• Do not place blame for defects or

problems on either partner• Pair should trust each other’s judgment

and loyalty to the team


Be aware of the power of two brains

• When two people working together, each has own set of knowledge and skills

• Large common subset allows to interact effectively

• Pool resources to accomplish tasks



What is NOT pair programming?

• Splitting up the work

• Taking turns doing the work

• One person doing all the work

• Being located in different places

• Sitting at different computers

• (Exception – it’s ok to use remote shared desktop technology, such as VNC, if absolutely necessary)


In-Class Workshop

• Form a pair right now (e.g., the person sitting next to you - this does not have to be the same person you will pair with for the team project!)

• Spend no more than 10 minutes developing a proposed solution to the assigned problem (to be announced in class)

• Spend no more than 5 minutes writing up your approach in the provided blue book (partners take turns writing)

• Submit before leaving class


Pair Formation assignment due Thursday September 14th

• Find a partner• Make sure your schedules are compatible!• Make sure you both use the same

language and platform!• Both submit the assignment (see website) • May optionally indicate the other pair with

whom you’d like to work in a team (otherwise will be assigned)

• Teams will be announced September 26th


Upcoming

• Individual development assignment #1 due September 19th

• Individual development assignment #2 due September 26th

• Teams announced September 26th• Team project concept due October 3rd

• Individual development assignment #3 due October 10th

• Revised project concept due October 17th


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


Documents

05 September 2006Kaiser: COMS W4156 Fall 20061 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser [email protected]