What is
Software Engineering
?
• NOT just programming
• NOT just programming [part of] a large
software system
• NOT just programming as a member of a
large team
What is
Software Engineering
?
“Software engineering is the application of a systematic,
disciplined, quantifiable approach to the development, operation, and maintenance of software.[1] The term software engineering was popularized during the 1968 NATO Software Engineering
Conference (held in Garmisch, Germany) by its chairman F.L. Bauer, and has been in widespread use since. The discipline of
software engineering encompasses knowledge, tools, and methods for defining software requirements, and performing software design,
software construction, software testing, and software maintenance
tasks.[2] Software engineering also draws on knowledge from fields such as computer engineering, computer science, management,
mathematics, project management, quality management, software
What do Software Engineers do?
• Anyone can call themselves a software
engineer, but not all programmers are software
engineers (and not all software engineers are
programmers)
• Newly hired software engineers typically
assigned to test or maintain someone else’s
pre-existing code
• Maintenance = Everything after initial
deployment
– When was the last time you used a commercial or open source program labeled “Version 1.0”?
What do Software Engineers do?
• 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
¾
Note: 4156 will focus primarily on developing
and testing your own very small
new software
Why
Study
Software Engineering?
• Writing a program
is
easy
– Program ~= code (possibly with comments)
• Developing a software system
is
harder
– System ~= program plus technical documentation sufficient such that someone other than original developers can maintain, typically involving
environmental interoperation (beyond just UI and file system)
• Developing a software product
is
very hard
– Product ~= system plus customers, fulfilling the
business needs of those customers, with customer-oriented documentation and support
Why
Study
Software Engineering?
• Software Engineering aims at supporting the
development of high-quality software products
– High-quality software products are more robust, efficient and effective
– High-quality software products are easier to use, understand, modify, and compose with other high-quality software products
¾
Note: 4156 will focus primarily on developing
and testing your very small
software system,
with no customers, for practical reasons
Why
Study
Software Engineering?
• To attain high-quality software, software engineers mustbe skilled professionals who follow defined processes and “best practices”
• Some schools offer entire degree programs in software engineering, not just a few CS courses (e.g., CMU, U. Texas at Austin)
• At present there is no licensing of software engineers in the US, only specialty “certifications” typically offered by vendors (e.g., IBM, Microsoft, Sun, Red Hat) but also by vendor-neutral organizations (e.g., IEEE, Linux
Professional Institute)
• Licensing of software engineers is very controversial, e.g., what would the Professional Engineer exam test?
Why is this course called
Advanced
Software Engineering?
• Until ~10 years ago, undergraduate CS majors were required to take COMS W3156 Introduction to Software Engineering, oriented towards sophomores and juniors, whereas 4156 was an equivalent elective oriented
towards seniors and graduate students
• Both courses presented a traditional view of the software lifecycle focused on detailed documentation,
independent of any particular technology, and stepped through the full lifecycle (through delivery to “customers”) • 4156 now concentrates on component model framework technology and emphasizes the software testing subset of a shortcut lifecycle
Course Outline
1. Component-based software development
– Component model frameworks (COM+, .NET, EJB, CCM, Web Services)
2. Quality assurance
– Code inspection, unit and integration testing, stress testing, test planning
3. Other software engineering topics as time
permits
– Pair programming, software process, requirements, UML, software architecture, design patterns,
Who am I?
• Gail Kaiser• 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 • 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
Who are you?
• Graduate and upper level undergraduate students in Computer Science, Computer Engineering, Biomedical Informatics, Electrical Engineering, maybe others
• Sincerely interested (hopefully) in learning to apply
Software Engineering methodologies and technologies – not just programming skills - to building and maintaining
useful and usable software products
• 4156 is required for the CS MS Software Systems track (unless you “import” a prior upper-level software
Textbooks
• Ron Patton,
Software Testing
, 2
ndedition,
Sams Publishing, ISBN 0672327988
(required)
• Clemens Szyperski,
Component Software:
Beyond Object Oriented Programming
, 2
ndedition, Addison-Wesley, ISBN
0201745720 (recommended)
• Ordered for this class through the
Columbia University Bookstore
Final Grade Breakdown
• 50%
Team
Project
– 2 iterations at 25% each
• 35%
Individual
Assessments [exams]
– 15% midterm – 20% final
• 15%
Individual
Development Assignments
– Three small homeworks to develop and demonstrate proficiency on component-based technologies
Team Project
• Students work primarily in pairs
(2 people)
• Grouped into 2-pair teams
(4 people)
• Each team will invent, design, code and test a
very small
software system using some
component model framework
• 2 rapid iterations of project - each 3-4 weeks long
• All major system functionality should be (more or
less) operational by the end of the 1
stiteration
Pairs and Teams
• Pairs ideally self-chosen – find a partner (if odd enrollment, one triplet permitted but no onesies) • 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
• Pairs within same team may be permitted to “switch” (discuss with instructor in advance!)
• Unattached individuals and pairs will be assigned by the teaching staff
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. Co-author project documentation
4. Demonstrate your project to the teaching staff
¾
All members of the same team must use the
same programming language (e.g., Java, C++,
C#), the same IDE (e.g., Netbeans, Eclipse,
VisualStudio), the same platform (e.g.,
Windows, Mac, Linux, Solaris), and the same
component model framework (e.g., EJB,
Frequently Asked Questions
• Do I have to join a pair/team?
9
YES!
• Can I do the project alone?
9
NO!
• I’m a CVN student, I work full time, I have a heavy class schedule, I have a long commute, I don’t like working in groups, I can only
program in an obscure scripting language that no one else knows, etc. - Can I do the project alone?
Individual Assessments
• Midterm and Final
• Take-home examinations that must be
completed by each student working individually
• Demonstrate your understanding of software
engineering principles and technologies, and
how they apply to your team project (graded)
• Evaluate your own, your partner’s and your
team’s work on the project thus far (not graded,
but contributes to project grade differentials)
Individual Development
Assignments
• Small design and programming homeworks
early in semester
• Must be done individually
(not with pair or team,
nor anyone else)
• Goal is to quickly come up to speed on
components and component model framework
technology
• Graded high-pass/pass/low-pass/fail (meaning
fail the course
– or drop the course – not just
lose 5% of the grade!)
First Assignments Due Next Week!
• Tuesday 11 September, 10am
• Assignments posted on course website
• Submit via CourseWorks
•
Individual Development Assignment #1
Course Outline
1. Component-based software development
– Component model frameworks (COM+, .NET, EJB, CCM, Web Services)
2. Quality assurance
– Code inspection, unit and integration testing, stress testing, test planning
3. Other software engineering topics as time
permits
– Pair programming, software process, requirements, UML, software architecture, design patterns,
What Is Pair Programming?
•
Two
software engineers work side-by-side
at
one
computer, sliding keyboard and
mouse back and forth (or simulated via
desktop sharing technologies)
• Continuously collaborate on same design,
algorithm, code, test, etc.
What Is NOT Pair Programming?
• Splitting up the work
• Taking turns doing the work
• One person doing all the work
¾
Note: 4156 requires pairs, but pair
programming is only encouraged, not
required
What About Productivity?
• Very controversial – common practice in some
software development organizations and unthinkable
in others
• Demonstrated in
some studies
to improve
productivity and quality of software products under
some circumstances
– Particularly novice-novice pairs (vs. novice solos) or expert-expert pairs (vs. expert solos)
– 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
Benefits
•
Increased discipline.
Pairing partners are more
likely to "do the right thing" and are less likely to
take long breaks.
•
Better code.
Pairing partners are less likely to
produce a bad design due to their immersion,
and tend to come up with higher quality designs.
•
Resilient flow.
Pairing leads to a different kind
of flow than programming alone. Pairing flow
happens more quickly: one programmer asks
the other, "What were we working on?"
Benefits
• Multiple developers contributing to design. If pairs are rotated frequently, several people will be involved in developing a particular feature. This can help create
better solutions, particularly when a pair gets stuck on a particularly tricky problem
• Improved morale. Pair programming can be more
enjoyable for some engineers than programming alone. • Collective code ownership. When everyone on a
project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire
