Application Design

1
Application Design Development (67-272)

• Dr. Kevin Stolarick

2
Agenda

• Introductions
• Administrivia
• Course Overview
• Why is software so bad?
• Personal Software Process

3
Introductions

• Name
• go by name
• PosCom
• Positive communication
• Something good and recent

4
Administrivia

• Quick Quiz
• projects?
• exams?
• Spell my name.

5
Administrivia

• Quick Quiz
• projects?
• 5
• exams?
• 3 (2 plus the final)
• Spell my name.
• Stolarick

6
Administrivia

• http//www.andrew.cmu.edu/course/67-272/
• Schedule
• General (IS) Policies
• Course Policies
• Projects
• Additional Material
• PHP and MySQL Web Development (Second Edition)
• Luke Welling and Laura Thomson
• ISBN0-672-32525-X

7
Administrivia

• TAs
• Graduate/Head TAs
• Plato Wai (ppw_at_andrew.cmu.edu)
• Charles Lee (cfl_at_andrew.cmu.edu)
• Undergraduate, 271 272
• Mon-Thurs, 630-900pm, PH A21A
• Starting on 9/7
• Sharon Blazevich
• Porter Hall 223E
• standard business hours (8-430)

8
Course Overview

• What is this course??
• What is 272?
• What is covered?

9
Course Overview

• Contrary to popular belief
• 272 is NOT a programming language course!

10
Course Overview

• 272 is
• Better programming
• Better practices processes
• Better design
• Better data (information) management
• Better testing
• Higher quality

11
Course Overview

• Will you program?
• Yes, new languages new technologies
• Why?
• Opportunity to practice new knowledge/processes
• Demonstrate competency
• Learn how to learn a new language

12
New programming/New approach

• Old way
• code and fix
• Programming by moonlight with Starbucks or
  Mountain Dew
• Beat the program into submission (at the last
  minute)
• Wont this still work?
• It might (especially first two projects)
• Long term -- asking for trouble

13
New programming/New approach

• Sunday night due date doesnt mean you can wait
  until Sunday morning (or Saturday or Friday) to
  start.
• What to do?
• Start early plan ahead
• Think design layout diagrams test cases
  before coding
• Ask for feedback

14
New programming/New approach

• Project Grading
• Quality, quality, quality
• Process as much as product
• Design as much as algorithms
• On time complete
• Thoroughly tested
• First, by you
• Then, by us

15
Is Software That Bad?

• Software Development crisis
• Successful - 16
• Challenged - 53
• Failed - 31
• Cost
• 85 gt 20 cost overrun 25 gt 100 over
• Time
• 86 gt 20 sched overrun 48 gt 100 over
• Function
• 93 less than full functionality
• 53 less than half requested functionality
• Large companies worse

16
How do YOU develop software?

• TYPICAL PROGRAM DEVELOPMENT PROCESS
• 1. Plan Analyze
• Obtain a description of the program to be
  completed. Understand requirements.
•  
• 2. Code and compile the solution
• Code and compile the solution. Refer to the
  assigned text and use good programming practices
  if time and patience permit. Fix syntax errors
  until program runs.
• 3. Test the program and remove defects
• Test the program with reasonable test data.
  Remove defects until it works (or seems to work).

17
A BETTER DEVELOPMENT PROCESS

• 1. Plan Analyze.
•  
• 2. Design the solution.
•  
• 3. Code the solution.  
• 4. Review your code.
• 5. Compile your code.
•  
• 6. Test the program and remove defects.
• Record entries in PSP Time Log throughout.
• Update PSP Project Plan when complete.

18
The Software Process

• A defined software process provides
• an orderly approach for doing the work
• a framework for measuring your work
• a basis for planning future jobs
• When you gather data on your work, you can use
  these data to plan your future jobs.
• By planning and tracking each program you
  develop, you will be better able to
• estimate and plan future work
• complete your work on time

19
The Improvement Process
20
Quality is JOB 1

• Quality is
• Your objective to reduce defects (shortcomings)
  in your own work processes
• Your Personal Quality Checklist
• Assignments and Projects
• Study and work habits
• Managing your time and your commitments
• Corollary Accepting Personal Responsibility is
  JOB 1.1

21
What's Your Personal Commitment to Quality?

• Attention to process, detail, and quality are
  fundamental ideas in Information Systems.
• There is no substitute for your personal
  commitment to quality in IS
• The motivation comes from within.
• The tools and training you learn along the way
  are proven to help.

22
The Personal Software Process

• The Personal Software Process (PSP) was developed
  to help software engineers do consistently
  high-quality work
• The PSP covers
• the methods for doing software work
• means for planning and tracking your work
• the principles to follow in producing quality
  products
• We modify the PSP somewhat to fit the needs of
  the IS curriculum and the time limits of the
  course. Using the PSP will help you improve your
  ability to do great work.

SM - The Personal Software Process and PSP are
service marks of Carnegie Mellon University
23
Course Requirements for PSP

• Course projects in 271/272 require various kinds
  of work
• Study, Preparation, Analysis, Planning
• Program Design
• Programming / Coding
• Testing, Debugging, Quality Assurance
• Writing / Documentation
• You will record the time you spend in each
  activity for each project.
• For 272, you will estimate the size and scope of
  each project in advance and later compare actual
  with estimated.
• You will get much better at time management and
  project planning and estimation.

24
The Project Plan

• The project plan contains estimates of
• the size of the product to be produced
• the time to develop the product
• the schedule for doing the work
• When software engineers plan their work, they
• can make realistic commitments for completing the
  job
• are more likely to finish on time
• By making plans for the small programs you
  develop in this course, you will practice the
  methods used for planning larger projects.

25
Estimation Job Size

• Product size measures are used to help make
  development estimates and plans.
• By estimating the size of the product to be
  developed, one can generally make a more accurate
  estimate of the required development time.
• By making better estimates, we can make better
  plans.

26
Estimation - Its Difficult

• Most Developers / Project Managers Dont Do it
  Well
• The Difficulties of Estimation
• What do you estimate?
• How do you estimate it?
• Not learning from experience
• No two projects are the same
• How do you factor in new technologies or
  methodologies?
• Best estimates result from well-kept history and
  careful analysis

27
Estimation - What to Estimate?

• What to estimate?
• Lines of Code (LOC)
• Function Points
• Use Case Points (UCPs)
• Effort in Person-Hours
• Effort in Calendar Days
• Budget
• Error Rates
• - We will use this in IS projects / project
  courses

28
Estimating Lines of Code (LOC)

• Used to be the Industry Standard
• still somewhat useful
• fairly easy to measure
• Measures nothing but code output
• Primitive measure of work effort, but hard to do
  early in life cycle before requirements are firm
• Difficult to apply to many applications
• Only count the code you write - not generated
  code.

29
Estimating Function Points

• Another Oldie, But Goodie - a step up from LOC
• Defined at the program, rather than system, level
• Weights program characteristics and complexity
• Inputs Screens, forms, GUI elements
• Outputs Screens, forms, graphs, messages
• Inquiries Trips to a database or file for
  immediate output
• Logical Internal Files Files or database tables
  used and controlled by the program
• External Interface Files Files or database
  tables used by the program but outside programs
  control

30
Estimating Use Case Points

• Contemporary measure - see pages 151-157 of
  Applying Use Cases (Project 2)
• Weights Actors and Use Cases adjusts for
  technical and environmental factors
• Appropriate throughout the life cycle - even
  before requirements are firm.
• Model is evolving - factors and weights may be
  adjusted based on experience
• Looks to be highly useful, accurate, scalable

31
Estimating Person - Hours

• Easiest Use a multiplier times estimated
  metric LOC, UCPs, FPs.
• Example Applying Use Cases recommends
  multiplying UCP by 20 person hours / UCP. So, 5
  UCPs becomes 100 hours of work.
• Part of our process is to come up with your own
  multipliers.
• Not so easy Use a formula or complicated
  software.

32
Estimating Calendar Days

• You must consider the estimated person-hours as
  well as all calendar considerations
• Weekends
• Holidays
• Vacations
• Other commitments

33
Time Management

• To better manage your time
• Analyze your own historical time data
• Establish a budget for spending your time
• Track your time against the budget
• Adjust your activities accordingly

34
Managing Commitments

• What is a commitment?
• Your intention to do something, and someone
  elses (or even your own) expectation that it
  will be done.
• Making responsible commitments
• Analyze the job, task, assignment before making a
  commitment
• Know what you can realistically agree to do
• Support the commitment with a plan and an
  agreement
• If unable to meet the commitment, promptly tell
  the other party try to minimize the impact
• Remember, you reputation is on the line!

35
Summary of Project 1

• Time on Task
• Median 20.6 hours
• Minimum 5.8 hours
• Maximum 43.9 hours

36
Project 1 Results

• 100 4 90-99 8 80-89 10 70-79 2
  60-69 1 50-59 3 40-49 0 30-39 1
  20-29 2 10-19 0 1-9 1 0
  4

• Late Projects 4
• Missing Projects 4