Rapid Software Development: Introduction

1
Rapid Software DevelopmentIntroduction

• Heng Ji
• hengji_at_cs.qc.cuny.edu
• Sept 9, 2008

2
Announcement

• Syllabus
• Team construction due Sept. 16, Project Proposal
  Write-up due Oct. 2
• No class this Thursday
• Guest Lecture Nov. 4
• Grading (Final)
• Presentation of Project Proposal (20)
• a 2-4 page write-up for project plans (10)
• a formal presentation (10)
• Project Implementation Source code, Interface
  and Documentation (60)
• Project Demo and Presentation (20)
• Textbook (encouraged to purchace)
• Steve C McConnell, Rapid Development Taming Wild
  Software Schedules.

3
Life-Cycle Planning Definition

• All the activities between the time that version
  1.0 of a system begins life as a gleam in
  someone's eye and the time that version 6.74b
  finally takes its last breath on the last
  customer's machine.
• A lifecycle model is a prescriptive model of what
  should happen between first glimmer and last
  breath.

4
Life-Cycle Planning Pure Waterfall
Not allowing you to back up to correct your
mistakes?
5
The Salmon Lifecycle Model
You can, but just difficult
6
Code-and-Fix Model
Default model for many people, it has no
overhead and requires little expertise But it
only works for TINY project its dangerous for
NON-TINY projects no means of assessing
progress or quality or identifying risks
7
Spiral Model

• Start small and expand the scope of the project
  in increments.
• Expand the scope only after you've reduced the
  risks for the
• next increment to an acceptable level.

8
Sashimi Model

• Overcome some of the weaknesses of the waterfall
  model by overlapping its stage
• But may be inefficient

9
Staged-delivery model
10
Design-to-Schedule Model
11
Evolutionary Delivery Model
12
Design-to-Tools Model
13
Choose a Life-Cycle Model
14
Goal Setting
15
Estimation

• Estimate the size of the product (number of lines
  of code or function points). Some projects jump
  right into estimating the schedule itself, but
  effective estimation requires estimating the size
  of the software to be built first. This step is
  by far the most difficult intellectually, which
  might be part of the reason that people so often
  skip it.
• Estimate the effort (man-months). If you have an
  accurate size estimate and historical data on
  your organization's performance on similar
  projects, computing the effort estimate is easy.
• Estimate the schedule (calendar months). Once
  you've estimated the size and effort, for reasons
  explained later in the chapter, estimating the
  schedule turns out to be nearly trivial. But
  getting a realistic schedule estimate accepted
  can be the most difficult part of the project. I
  devote the entire next chapter to that topic.

16
Scheduling
17
Scheduling (Cont)
18
General Strategy for Rapid Development

• Avoid classic mistakes.
• Apply development fundamentals.
• Manage risks to avoid catastrophic setbacks.
• Apply schedule-oriented practices

19
Four Dimensions of Development Speed

• People perform quickly, or they perform slowly.
• The process leverages people's time, or it throws
  up one stumbling block after another.
• The product is defined in such a way that it
  almost builds itself, or it is defined in a way
  that stymies the best efforts of the people who
  are building it.
• Technology assists the development effort, or it
  thwarts developers' best attempts.

20
General Kinds of Fast Development
21
Classic Mistakes

• Effect of Mistakes on a Development Schedule
• Productivity of projects in the High category
  varied from poor to excellent
• Classic Mistakes Enumerated

22
Classic Mistakes (Cont)
23
Software-Development Fundamentals

• Management Fundamentals
• Technical Fundamentals
• Quality-Assurance Fundamentals
• Everybody wants to be on a championship team, but
  nobody wants to come to practice.
  - Bobby Knight

24
Management Fundamentals

• Estimation and Scheduling
• the size of the project
• the effort needed to build a product of that size
• a schedule based on the effort estimate
• Planning and Tracking
• Measurement

25
Technical FundamentalsRequirements Management

• Requirements-analysis methodologies
• structured analysis
• data structured analysis
• object-oriented analysis
• System-modeling practices
• class diagrams, dataflow diagrams,
  entity-relationship diagrams, data-dictionary
  notation, and state-transition diagrams
• Communication practices
• Joint Application Development (JAD)
• user-interface prototyping
• general interview practices

26
Technical FundamentalsDesign

• Major design styles (such as object design,
  structured design, and data-structure design)
• Foundational design concepts (such as information
  hiding, modularity, abstraction, encapsulation,
  cohesion, coupling, hierarchy, inheritance,
  polymorphism, basic algorithms, and basic data
  structures)
• Standard design approaches to typically
  challenging areas (including exception handling,
  internationalization and localization,
  portability, string storage, input/output, memory
  management, data storage, floating-point
  arithmetic, database design, performance, and
  reuse)

27
Technical FundamentalsDesign (Cont)

• Design considerations unique to the application
  domain you're working in (financial applications,
  scientific applications, embedded systems,
  real-time systems, safety-critical software, or
  something else)
• Architectural schemes (such as subsystem
  organization, layering, subsystem communication
  styles, and typical system architectures)
• Use of design tools

28
Technical FundamentalsConstruction

• Coding practices (including variable and function
  naming, layout, and documentation)
• Data-related concepts (including scope,
  persistence, and binding time)
• Guidelines for using specific types of data
  (including numbers in general, integers,
  floating-point numbers, characters, strings,
  Booleans, enumerated types, named constants,
  arrays, and pointers)
• Control-related concepts (including organizing
  straight-line code, using conditionals,
  controlling loops, using Boolean expressions,
  controlling complexity, and using unusual control
  structures such as goto, return, and recursive
  procedures)
• Assertions and other code-centered
  error-detection practices

29
Technical FundamentalsConstruction (Cont)

• Rules for packaging code into routines, modules,
  classes, and files
• Unit-testing and debugging practices
• Integration strategies (such as incremental
  integration, big-bang integration, and
  evolutionary development)
• Code-tuning strategies and practices
• The ins and outs of the particular programming
  language you're using
• Use of construction tools (including programming
  environments, groupwork support such as email and
  source-code control, code libraries, and code
  generators)

30
Project Proposal Examples and Tips

• http//nlp.cs.qc.cuny.edu/DraftNameTranslationPlan
  .pdf
• http//readyset.tigris.org/nonav/templates/proposa
  l.html
• http//www.eee.metu.edu.tr/design/proposal.htm
• http//www.klariti.com/templates/Proposal-Template
  .shtml