Software Development

1
Software Development
2
The Software Life Cycle

• Encompasses all activities from initial analysis
  until obsolescence
• Analysis of problem or request
• System development and installation
• System use and maintenance
• System removal/replacement
• Need a roadmap for development of large systems

3
Process Model for Developing Software

• The purpose of a development model is
• improve productivity, timeliness, and software
  quality.
• The development model should
• describe the phases of the development process
• give guidelines for how to carry out the phases.
• provide methodologies that are predictable and
  repeatable.

4
Software Development

• Five Phases
• Analysis
• Design
• Implementation
• Testing
• Deployment
• Variety of development models

5
Analysis

• Decide WHAT the project is supposed to
  accomplish. (Not HOW.)
• Produce a requirements specification.
• Precisely describe the software to be written
• Describe performance criteria
• How large can the input set be?
• How fast must the data be handled?
• What is the maximum amount of memory or disk
  space that the program may use?
• Do not be ambiguous.
• Develop a testing plan
• Determine what will prove that the system
  fulfills requirements
• Produce a user manual
• tells how user will operate program

6
Design

• Develop a high level system architecture.
• Use diagrams to visualize project
• What data structures make sense?
• Will this design meet the specification?
• For Object Oriented designs
• What classes will you use?
• What are their significant methods?
• What are the relationships between classes?

7
Implementation

• Write the code that follows the design.
• implement classes and methods discovered in the
  design phase
• Compile the code
• handle syntax errors

8
Testing

• Run tests to verify the program works correctly
• Use testing plan from the analysis phase
• Discover/fix bugs
• Unit testing
• tests a single method or a set of cooperating
  methods
• perhaps the most important testing tool
• E.G., JUnit tests (built into eclipse)
• Integration testing
• tests a set of cooperating modules.
• Systems testing
• tests an integrated system to verify/validate
  that it meets its requirements.

9
Maintenance

• The software is released to the customer
• Fix bugs.
• Add new features.
• Update to work with new hardware and operating
  systems.
• About ? of all software engineering work is
  maintenance.

10
Fixing problems

• It is easier to fix a problem found early rather
  than late in software development.
• Better to find problems in the design phase than
  in the implementation phase.
• Better to find problems in the implementation
  phase than in the testing phase.

11
Software Development Models

• Waterfall model
• Iterative models
• Spiral model
• RUP model
• Agile model
• Extreme Programming
• Others

12
Waterfall Model
Analysis
Design
Implementation
Testing
Maintenance
13
Waterfall Model

• Legacy model
• has been in use since the 1970s
• Characterized by completely finishing a step
  before proceeding to the next step.
• once a step is finished, it is not revisited
  (when this model is rigidly followed).
• Large government agencies still use forms of this
  model
• prefer to spend large amounts of effort on
  analysis and requirements before awarding
  contracts.

14
Waterfall Model

• Pros
• Like the BDUF (Big Design Up Front) models, the
  waterfall model encourages engineers to think
  through the details before coding begins.
• Problems are identified early in the process
  which saves time and effort later.
• Cons
• Software engineers cannot predict the future and
  anticipate every requirement and problem.
• This model is not flexible enough to allow
  requirements to evolve.

15
Iterative process models

• Spiral development
• RUP (Rational Unified Process)
• XP (eXtreme Programming)

16
Spiral (Iterative) Model
Design
Analysis
Implementation
Prototype 1
Prototype 2
Final Product
Testing
Maintenance
17
Spiral or Iterative Model

• Characterized by the use of prototypes.
• Prototypes allow
• feedback between the engineers and the customer.
• lessons learned from development of one prototype
  to be applied to the next iteration
• the direction of the project to be reevaluated.
• specifications to be added.

18
Spiral or Iterative Model

• Pros
• More flexible than the waterfall model.
• Projects can evolve.
• Cons
• Engineers know that they dont have to do a
  thorough job at each step because steps are
  revisited.
• Too many iterations can cause project delays.

19
RUP(Rational Unified Process)

• Essentially iterates all phases during each phase
  
• Inception
• Elaboration
• Construction Planning
• Construction
• Transition

20
Activity Levels in the Rational Unified Process

• Development model by the inventors of UML
  (Unified Modeling Language)

Interested? Look up RUP articles by Grady Booch
Activity Levels in the Rational Unified Process
Methodology
21
Agile Model

• Agile processes use feedback (rather than
  planning) to control the process.
• Agile methods emphasize real-time communication
• preferably face-to-face, over written documents.
• Most agile methods try to minimize risk by
  developing software in short iterations
• typically last one to four weeks
• each iteration is like a miniature software
  project of its own.

22
Extreme Programming - XP

• Best-known agile development model.
• First, write automated tests to provide concrete
  goals for development.
• Test-Driven Development, TDD
• Next, coding (by a pair of programmers)
• complete when all the tests pass and the
  programmers can't think of any more tests that
  are needed.

23
Extreme Programming - XP

• Code is refactored.
• doesnt fix bugs or add new functionality.
• done to improve understandability and clarity of
  structure, code clean up.
• design and architecture emerge during this step.
• The incomplete but functional system is
  demonstrated to the customer.
• Repeat the cycle by writing tests for the next
  most important part of the system.

24
The 12 practices of XP

1. Realistic planning with frequent iteration
   well-defined decision-making structure
2. Small releases (juiciest first)
3. Metaphor (big picture)
4. Simple design
5. Refactoring (continuous design)
6. Testing (test and then code)
7. Pair programming
8. Collective ownership (by small co-located teams)
9. Continuous integration
10. 40-hour week
11. On-site customer
12. Coding standards

Interested? Look up agile programming articles by
Jim Highsmith