Introductory Software Engineering CSE100

1
Introductory Software EngineeringCSE100

• Key Concepts Ideas in SE

2
Whats it all for anyway?

• Could you get through your degree without
  studying SE?
• For individual assignments you could build small
  programs without necessarily doing SE (depending
  on what documentation your tutor wants) you
  could hack your code together instinctively if
  you only have yourself to answer to
• Your level 2 project where you are part of a
  team - requires that you understand and use SE
  concepts
• Your level 3 project requires you to develop for
  a client to write a dissertation documenting
  your work that needs SE knowledge
• Most importantly without it you couldnt get a
  job in industry as a software developer, working
  in a complex team, doing a job on one small part
  of a large, complex project

3
Consider

• If you build a great kennel for your pet dog,
  does that mean you could build a skyscraper?
• Its not just a bigger building
• It requires
• different approach,
• different raw materials,
• different constraints e.g. appearance, health
  safety, quality standards etc
• more people,
• management,
• larger budget
• etc

4

• In this session well look at important concepts
  in SE
• Some have changed through the years since 1970s
• New ones have been added
• Some taken away
• Some remain constant

5

• 10 Ideas originally from Ed Yourdon with
  pointers to all sources
• www.yourdon.com/downloads

6
Top 10

• You cant control what you cant measure
• Peopleware
• Incrementalism
• Iteration
• Repair costs increase with time

• Tradeoffs are non-linear
• Reuse
• Risk Management
• Consistency
• Dont reinvent the wheel

7
1. You cant control what you cant measure

• What if youre on a calorie controlled diet but
  you have no calorific data on your available
  foodstuff
• What if I said Im going to get you to score
  better marks than last years SE students? What
  would I need? How to measure?

8

• What if I set you a competition to build a bridge
  and I was going to award prizes? How would I
  judge it?
• Same if I challenged you to build the best
  website
• How to judge?

9

• SE employs METRICS
• Core Metrics to measure
• e.g. size, effort, defects, turnover
• Soft Metrics to measure
• Human factors e.g. User satisfaction or morale

10
2. Peopleware

• Consider
• Have you ever had a job you hated?
• Why did you hate it?
• e.g. Did you feel undervalued/unrewarded?
• How did you react?
• People are the biggest productivity factor in a
  company/on a project
• Hire the best, have best HR strategy e.g. Googles

11
3. Incrementalism is essential

• Means Do a bit at a time
• Why bother?
• You get feedback on the SW, the development
  process, on the people/developers capability
• You can make changes to the initial plan as you
  go along i.e. ADAPT

12
4. Iteration is essential

• Means Do the same thing again and again
• You dont know what the end product will be
• You can iterate within or across software
  development activities
• Analysis, design, development, testing,
• (In OO Object Oriented approach - an example
  of iteration is refactoring improving
  appearance, maintainability etc but not function)

13
5. Repair costs increase with time

• i.e. the more youve already done, the
  worse/dearer/more complicated it gets to change
  anything
• AGILE developers disagree with this idea, saying
  it isnt true if you use their methods (including
  refactoring)
• Many insist its always true, possibly depending
  on project size though.

14
6. Tradeoffs are non-linear

• If you are struggling to finish a project on
  time, should you
• Employ more people
• Cut down the scope of the project
• Why?

15
Correct answer is

• Cut down the scope of the project
• If you employ more people you have to bring them
  up to speed, you increase communication
  complexity may need to have more meetings etc
• Remember Nine women cant produce a baby in a
  month
• (Hayler, 2005 andyonenterprisesoftware.com)

16
7. Reuse

• Not just code but everything you do in SE process
• Specifications, design, code, processes etc
• E.g., consider Mashups (ad hoc Web sites created
  on the fly out of other Web sites,
• Click on http//news.zdnet.com/2422-13569_22-1527
  29.html or http//uk.youtube.com/watch?vZRcP2CZ8
  DS8 for video
• Also http//uk.youtube.com/watch?voMlEggjjrik
• Some people think theyre the next big SE
  development model
• http//blogs.zdnet.com/Hinchcliffe/?p106

17
8. Risk Management

• Important - as it not being done is a big reason
  for projects failing
• http//csqa.info/
• RM attempts to manage uncertainty in order to
  deal with
• scarce resources,
• advances in technology,
• increased demand for complex systems in rapidly
  changing environment.
• Must be performed regularly throughout the SW
  life cycle because risks are dynamic i.e. they
  change over time
• RM techniques introduced to the software
  community in 1980s by Barry Boehm who also
  invented the Spiral Model, a software lifecycle
  model that is iterative and risk driven.

18
RM

• Implementing RM successfully is a cultural rather
  than technical problem because people may
  perceive it as extra work that is less important
  to the actual development
• Its peripheral to the development itself e.g.
  it might consider should you employ junior or
  senior programmers?

19
9. Consistency trumps brilliance death march

• A measured and well documented approach is better
  than either
• random brilliance or
• those situations where a project is destined to
  fail because of gross over-optimism or negligence
  in early stages (planning, reqts, risk
  management etc)

20
10. Dont reinvent the wheel

• There is a huge body of knowledge in SE
• E.g. the SWEBOK
• http//www.swebok.org/
• Its often overlooked because the SE industry is
  constantly recruiting new, young people
• Who may think they know better, or
• May think the body of knowledge has nothing to
  offer new types of SW development

21
Top 10

• You cant control what you cant measure
• Peopleware
• Incrementalism
• Iteration
• Repair costs increase with time

• Tradeoffs are non-linear
• Reuse
• Risk Management
• Consistency
• Dont reinvent the wheel

22
Other ideas lists overlap but some extra points

• http//www.construx.com/
• 11. Grain of Truth in the Waterfall Model
• 12. Accuracy of estimates increases with time
• Estimate iteratively
• Project plan incrementally
• 13. Different software types need different
  development approaches

23
Top 10 influences on SE evolution

• Reviews and Inspections
• Information Hiding
• Incremental Development
• User Involvement
• Automated Revision Control

• Programming Languages Hall of Fame
• Capability Maturity Model
• Object Oriented Programming
• Component Based Development
• Metrics and Measurement

http//www.stevemcconnell.com/ieeesoftware/eic09.h
tm Written in year 2000
24
1. Reviews and Inspections

• "egoless programming
• no matter how smart a programmer is, reviews will
  be beneficial.
• Fagan Inspections
• Hugely improve quality, cost scheduling

25
2. Information Hiding

• Hiding design decisions in a program that may
  change in order to protect other parts of the
  program if the design decision is changed
  (Wikipedia)
• Sometimes called encapsulation, sometimes
  confused with abstraction
• Easier to debug, and less bugs

26
3. Incremental Development

• the daily build is the best example of a
  real-world approach that works. It minimizes
  integration risk, provides steady evidence of
  progress to project stakeholders, keeps quality
  levels high, and helps team morale because
  everyone can see that the software works

27
4. User Involvement

• Important because reqts stage problems cause
  most failures in SW projects
• techniques that bring users more into the
  software product design process e.g.
• User interface prototyping
• Use cases

28
5. Automated Revision Control

• methods for organizing large numbers of
  programmers efficiently
• But only of real use on large team projects?

29
6. Programming Languages Hall of Fame Fortran,
Cobol, Turbo Pascal, Visual Basic

• Certain languages and generations of languages
  had huge impacts on SE evolution, e.g.
• Cobol (wrongly?) blamed for Y2K
• Academics and researchers talked about
  components and reuse for decades, and nothing
  happened. Within 18 months of Visual Basics
  release, a thriving pre-built components market
  had sprung from nothing. The direct-manipulation,
  drag-and-drop, point-and-click programming
  interface was a revolutionary advance.
• See website for comments on other languages

30
7. Capability Maturity Model for Software
(SW-CMM)

• Arguable whether good or bad.
• Some feel it has had a huge impact on 1000s of
  organisations
• Some think its too rigid
• The main point is the recognition of a need for
  standardized software processes.

31
8. Object Oriented Programming

• A programming paradigm that uses objects and
  their interactions
• the real benefit of object oriented programming
  is probably not objects, per se, but the ability
  to aggregate programming concepts into larger
  chunks than subroutines or functions.

32
9. Component Based Development

• Break down the system into functional or logical
  components with well defined interfaces for
  communicating across
• Work on components helped to see the direction
  towards frameworks, reuse, and pattern languages.
  So it is a useful intermediate step. Thinking in
  components still is a good design principle.

33
10. Metrics and Measurement

• A metrics discipline in software engineering is
  as necessary as theoretic foundations are in
  other engineering disciplines to avoid software
  development approaches that are built on nothing
  more than gut feeling.
• Metrics are a problem. Our foundations are off
  badly in this area, because we keep trying to
  apply variations of the metrics that worked well
  for manufacturing to the highly creative design
  problems of software. Its a lot like trying to
  teach people how to write like Shakespeare by
  constantly checking their words for spelling
  errors.

34
Internet Development

• An 11th point
• Open Source development is just the beginning of
  collaborative efforts made possible via the
  Internet. The potential this creates for
  effective, geographically distributed computing
  is truly mind boggling.
• See earlier point on Mashups!

35
Just to finish on the Top 10 theme

• Top 10 traits of a rockstar software engineer
  http//www.readwriteweb.com/archives/top_10_softwa
  re_engineer_traits.php