Further Aspects of Database Design, Software Engineering and Project Kickoff

1
Further Aspects of Database Design, Software
Engineering andProject Kickoff
2
Database Design Topic

• Natural vs. Generated Keys

3
Definitions

• Natural keya key that occurs in the data, that
  serves as a unique identifier for rows
• Generated keya key that is generated in order to
  make rows unique

4
Generated Keys

• In some organizations, programmers have the idea
  that generated keys should be included in every
  relationthis is a misunderstanding of the
  relational approach.
• Thats a fine idea for an Excel spreadsheet but
  it shows a misunderstanding of what a relation is
  and what a tuple is.
• Tuples are naturally unique because each one
  corresponds to a distinct instance of an entity
  type in the real world. You dont have to add
  anything to make them unique.
• If your database design is correct, you have
  unique rows even if you havent added a key to
  each row.

5
When to Use Generated Keys

• Sometimes you have a compound key that is very
  long
• Lots of queries will be very complicated and
  tables with foreign keys will copy most of
  another table
• As a guideline, the only time to use a generated
  key is when the natural key has at least three
  columns

6
Software Engineering

• Wicked Problems

7
Wicked Problems

• The pointthe traditional approach to software
  engineering is fundamentally unsuitable. A
  different approach is needed.
• We will use an approach that recognizes the
  nature of software designits usually a wicked
  problem. Our approach will seem undisciplined
  but is superior to the traditional approach.
• We will employ just-in-time database design as
  the central coordination mechanism for the
  project.

8
Important MCC Study

• MCC studied how experienced, highly successful
  designers of elevators approached design problems
• During actual design, they watched their behavior
  to observe the phases of design and the sequence
  in which they executed the various phases
• MCC researchers found that the actual approach
  used was very different from formal methods that
  we advocated
• The designers transitioned regularly back and
  forth from one phase to another

9
Traditional Approach
10
What Is Actually Done
11
Tame Problem

• Has requirements that are well defined at the
  outset
• Requirements stay constant during the design and
  implementation
• Stakeholder interests are well established and
  constant during the effort
• The solution is known and recognizable

12
Wicked Problem

• You don't understand the problem until you have
  developed a solution.
• Multiple stakeholders
• You may need to adjust the requirements based on
  solutions that can be developed
• Constraints on the solution change over time.
• Stakeholders come and go, change minds, fail to
  communicate, change the rules.
• No definitive Problem, no definitive Solution.

13
Which Problems Are Wicked?

• Design and launch a satellite
• Design a new car
• Design a bridge over the Potomac
• Route a new highway
• Reorganize your department
• Develop a new kind of bullet-resistant glass that
  is half the weight of current products for the
  same bullet resistance

• Design an electric motor, given power, speed,
  weight requirements
• Devise a mission statement for your company
• Design a personal information manager for your
  own use
• Design a folksonomic collaborative Web site

14
Most software development efforts of interesting
scope today are wicked problems.
15
Whats A Wicked Problem

• A wicked problem is an evolving set of
  interlocking issues and constraints. A linear
  approach to solving a wicked problem simply will
  not work.

16
Project Kickoff

• Responsibilities, How to Proceed

17
Typical Project

• The project assignment tells you everything you
  have to do
• The scope of the project is limited to some
  specific area
• Just program what they say, ease of use or
  functional completeness are not issues
• You look for the easiest way to meet the
  requirements and thats what you build
• Get on a team with someone who has experienced
  and watch them build it.

18
This Project

• Its more like a professional assignmentthe
  requirements are not complete
• The customer (professor) may change the
  requirements after work starts
• Teams may discover that additional functions are
  needed, in addition to what was planned
• The customer may make changes if unhappy how
  screens work
• The responsibility of the whole class is to
  deliver an application that workscompletely
• No one gets a successful project grade unless the
  whole thing works and works professionally

19
How To Succeed

• Build strong relationships with your team members
• If someone asks for help through email, help
  themyou may need help yourself later
• Be very careful to be extremely politedisputes
  waste time, and we dont have it to spare
• Make all communication with other project
  participants through the email address. This is
  important to let everyone know whats going on

20
The Project

• We are building a professional practice site
• http//www.officevisit.info
• The site will be a service for clients of a
  professional practice
• First, the practice owner signs up for the
  service
• Practice owner sets various parameters for the
  practice
• The practice owner then assigns userids and
  passwords to her clients
• Clients can then log in and see their statements
  and make appointments
• Security
• Practices are kept separate and client
  information is kept private
• Customer-readable tables have read and update for
  PUBLIC
• Translucent database techniques keep things
  private

21
How We Will Proceed on the Project

• Involve everyone customers, developers, system
  engineers
• Lots of dialogue
• Flexibility in order of work
• Development teams choose what they program,
  encourage SET to complete database design in that
  area
• Encourage Openness
• Teamwork is facilitated
• Completely inform everyone
• All emails about project to every member
• Avoid time-wasting struggles
• Personal disputes are forbidden
• Look at possible solutions early
• Early mockup of final site

22
Guidelines

• All phases of work start on Day 1
• Every member of each group does a major favor,
  early, for every other member
• Group decisions guide just-in-time database
  design work
• All email communications must use the class email
  list, so that they go to all project members
• Criticism of another project member is absolutely
  forbidden

23
System Engineering Team

• Produces no code of their own
• Responsible for database design, overall project
  success
• Organizes schedule
• Establishes procedures for code submission,
  release of systems
• Conducts system testing
• Administers Web site contents

24
System Engineering Team

• Organize your team
• Decide on responsibilities for each person
• Submit responsibilities to Henry
• Show the team youre on, what you will do
• Organize configuration control
• How do teams do testing? On their machines or a
  test domain?
• How do teams submit pages? How do handle shared
  functions?
• Start on database design now
• Get information from programming teams about
  important entity types
• Start with whats most important to the
  programmers
• Recommendation sketch in the whole thing, then
  start on the most important entity types
• Develop a schedule for the project
• Date for completion of use cases
• Date for completion of draft screens
• Dates for code delivery
• Date for first test, preacceptance test,
  acceptance test

25
Programming Teams

• Organize your team
• Decide who programs what
• submit responsibilities to Henry next week
• Show which team you are on, what you will do
• Decide what entities are most important
• Sketch in a database design, send it to SET
• Start programming
• Develop use cases
• Decide who are users, how each user uses your
  pages
• Submit to the whole class and Henry on due date
• Develop draft screens
• Submit first draft screen with each use case
• Later, deliver draft screens to Henry and demo in
  class

26
Keep This In Mind

• We dont have a lot of time
• Make things happen in parallel
• Get to something that works as soon as possible
• As soon as something works, show it to the
  customer (professor)
• Get customer feedback early and often
• Identify problems early and get them resolved
• Give each other feedback
• Programming teams help SET with schedules, plans
  that they set
• SET, seek advice, evolve plans with programming
  team participation

27
What Were Doing Now

• We will take a break and have team meetings
• Do your first round of planning
• Submit results to Henry no later than this Friday