During the Spring semester, I teach a 3 credit survey course in software development, at UW-Madison (IS 371), which is the first in the series of courses in the Information Systems major track. As part of this course, I devote an entire lecture to discussing different types of software development (Agile, Waterfall, Extreme, Spiral, etc.) I hope it helps the students better understand the different types of software development styles, as well as the benefits and drawbacks of each. In my opinion, they need to learn early on that there is more than one way to go about a software development challenge, and they need to figure out which style works best for them.

1. Information Systems 371
Lecture 3, January 29, 2019
Topic: Software Development Methodologies
Lecturer: Nicholas Davis

2. Let’s Start With Some
Humor Related to RAD
(Rapid Application Development)
1/28/2019 UNIVERSITY OF WISCONSIN 2

3. Housekeeping
• Did everyone get the email I sent on Monday? If
not, please write down your email address and
give it to me at the end of class
• Is the installation of Visual Studio going OK
• Programming assignments: What is the best way
to learn? How do we avoid having anyone left
behind?
• Is class going OK? Would you tell me if it wasn’t.
I don’t want to learn about it at the end of the
semester
• How about a visit from Epic?
1/28/2019 UNIVERSITY OF WISCONSIN 3

4. Interesting Article
Does Hardware Even Matter
Anymore?
• https://hbr.org/2015/06/does-
hardware-even-matter-anymore
• Are you a hardware person or a
software person?
• Which areas of information systems
interest you most, and where do you
envision the biggest opportunities?
1/28/2019 UNIVERSITY OF WISCONSIN 4

5. You Don’t Just “Program”,
You “Develop Software”
• In software engineering, a software
development process is the process of
dividing software development work
into distinct phases to improve design,
product management, and project
management
1/28/2019 UNIVERSITY OF WISCONSIN 5

6. Software Development
• Most modern development processes
can be vaguely described as agile.
Other methodologies include
waterfall, prototyping, iterative and
incremental development, spiral
development, rapid application
development, and extreme
programming.
1/28/2019 UNIVERSITY OF WISCONSIN 6

7. Agile
Software Development
• Agile software development describes an
approach to software development under
which requirements and solutions evolve
through the collaborative effort of self-
organizing cross-functional teams and their
customer/end users
• It advocates adaptive planning, evolutionary
development, early delivery, and continuous
improvement, and it encourages rapid and
flexible response to change
1/28/2019 UNIVERSITY OF WISCONSIN 7

8. “Pair Programming”
in Agile Development
1/28/2019 UNIVERSITY OF WISCONSIN 8

9. Waterfall (Old School)
Software Development
1. System and software requirements: captured in a
product requirements document
2. Analysis: resulting in models, schema, and business
rules
3. Design: resulting in the software architecture
4. Coding: the development, proving, and integration
of software
5. Testing: the systematic discovery and debugging of
defects
6. Operations: the installation, migration, support, and
maintenance of complete systems
1/28/2019 UNIVERSITY OF WISCONSIN 9

10. Waterfall Usually Has 5 or 6
Steps
1/28/2019 UNIVERSITY OF WISCONSIN 10

11. Prototyping
Software Development
Software prototyping is the activity of creating
prototypes of software applications, i.e., incomplete
versions of the software program being developed. It
is an activity that can occur in software development
and is comparable to prototyping as known from
other fields, such as mechanical engineering or
manufacturing.
A prototype typically simulates only a few aspects of,
and may be completely different from, the final
product.
1/28/2019 UNIVERSITY OF WISCONSIN 11

12. Prototyping
1/28/2019 UNIVERSITY OF WISCONSIN 12

13. Iterative
Software Development
• Worst definition EVER: Relating to or
involving iteration, especially of a
mathematical or computational
process.
• You start by writing a general
application, but then come back to it
to add a few more features at a time,
over and over, evolving over time
1/28/2019 UNIVERSITY OF WISCONSIN 13

14. Iterative
Software Development
1/28/2019 UNIVERSITY OF WISCONSIN 14

15. Spiral Software Development
Don’t even bother learning about this. It is rarely
used, and overly complex. Forget about it!
1/28/2019 UNIVERSITY OF WISCONSIN 15

16. Rapid Application Development
• RAD approaches to software development put
less emphasis on planning and more emphasis on
an adaptive process. Prototypes are often used in
addition to or sometimes even in place of design
specifications.
• RAD is especially well suited for (although not
limited to) developing software that is driven by
user interface requirements. Graphical user
interface builders are often called rapid
application development tools.
1/28/2019 UNIVERSITY OF WISCONSIN 16

17. Extreme Software Development
• A flat management structure, code simplicity and
clarity, expecting changes in the customer's
requirements as time passes and the problem is
better understood, and frequent communication
with the customer and among programmers
1/28/2019 UNIVERSITY OF WISCONSIN 17

18. Extreme Programming
1/28/2019 UNIVERSITY OF WISCONSIN 18

19. Software Development
Life Cycle (SDLC)
• The systems development life cycle (SDLC), also
referred to as the application development life-
cycle, is a term used in systems engineering,
information systems and software engineering to
describe a process for planning, creating, testing,
and deploying an information system.
• Uses an enhanced Waterfall methodology
• Talk about it at a job interview to sound smart
and eat up a bunch of time!
1/28/2019 UNIVERSITY OF WISCONSIN 19

20. SDLC
8 Phases
1. System investigation
2. System analysis
3. Design
4. Environments
5. Testing
6. Training and transition
7. Operations and maintenance
8. Evaluation
1/28/2019 UNIVERSITY OF WISCONSIN 20

21. SDLC
System Investigation
• The system investigates the IT proposal. During this step, we must consider all current
priorities that would be affected and how they should be handled. Before any system
planning is done, a feasibility study should be conducted to determine if creating a new or
improved system is a viable solution. This will help to determine the costs, benefits, resource
requirements, and specific user needs required for completion. The development process
can only continue once management approves of the recommendations from the feasibility
study.
• Following are different components of the feasibility study:
• Operational feasibility
• Economic feasibility
• Technical feasibility
• Human factors feasibility
• Legal/Political feasibility
1/28/2019 UNIVERSITY OF WISCONSIN 21

22. SDLC Systems Analysis
• The goal of system analysis is to determine where
the problem is, in an attempt to fix the system.
This step involves breaking down the system in
different pieces to analyze the situation,
analyzing project goals, breaking down what
needs to be created and attempting to engage
users so that definite requirements can be
defined.
1/28/2019 UNIVERSITY OF WISCONSIN 22

23. SDLC Design
• Describes desired features and operations in
detail, including screen layouts, business rules,
process diagrams, pseudocode and other
documentation.
1/28/2019 UNIVERSITY OF WISCONSIN 23

24. SDLC Development
• Environments are controlled areas where
systems developers can build, distribute, install,
configure, test, and execute systems that move
through the SDLC. Each environment is aligned
with different areas of the SDLC and is intended
to have specific purposes. Examples of such
environments follow on the next slide.
1/28/2019 UNIVERSITY OF WISCONSIN 24

25. SDLC Development
• Development environment, where developers can
work independently of each other before trying to
merge their work with the work of others,
• Common build environment, where merged work
can be built, together, as a combined system,
• Systems integration testing environment, where
basic testing of a system's integration points to other
upstream or downstream systems can be tested,
• User acceptance testing environment, where
business stakeholders can test against their original
business requirements,
• Production environment, where systems finally get
deployed to, for final use by their intended end users.
1/28/2019 UNIVERSITY OF WISCONSIN 25

26. Do You Know the Dos Equis Guy?
“I don’t always drink beer, but when I do,
I choose Dos Equis”
1/28/2019 UNIVERSITY OF WISCONSIN 26

27. In a Previous Life,
He Was a Software Developer,
But Got Fired
1/28/2019 UNIVERSITY OF WISCONSIN 27

28. SDLC Testing
• The code is tested at various levels in software
testing. Unit, system and user acceptance testings
are often performed. This is a grey area as many
different opinions exist as to what the stages of
testing are
1/28/2019 UNIVERSITY OF WISCONSIN 28

29. So Much Testing in the SDLC
• Path testing
• Data set testing
• Unit testing
• Integration testing
• System testing
• Black-box testing
• White-box testing
• Regression testing
• Automation testing
• User acceptance testing
• Software performance testing
1/28/2019 UNIVERSITY OF WISCONSIN 29

30. Path Testing
• Does data move through the system in the
manner you expect?
1/28/2019 UNIVERSITY OF WISCONSIN 30

31. Data Set Testing
• Test data is data which has been specifically
identified for use in tests, typically of a computer
program.
• Some data may be used in a confirmatory way,
typically to verify that a given set of input to a
given function produces some expected result.
Other data may be used in order to challenge the
ability of the program to respond to unusual,
extreme, exceptional, or unexpected input.
1/28/2019 UNIVERSITY OF WISCONSIN 31

32. Unit Testing
• Is a software testing method by which individual
units of source code, sets of one or more
computer program modules together with
associated control data, usage procedures, and
operating procedures, are tested to determine
whether they are fit for us
1/28/2019 UNIVERSITY OF WISCONSIN 32

33. Integration Testing
• Is the phase in software testing in which
individual software modules are combined and
tested as a group. It occurs after unit testing and
before
1/28/2019 UNIVERSITY OF WISCONSIN 33

34. System Testing
System testing of software or hardware is testing
conducted on a complete, integrated system to
evaluate the system's compliance with its specified
requirements.
1/28/2019 UNIVERSITY OF WISCONSIN 34

35. Black Box Testing
• You put something you know, into the system.
You expect to get a certain result. Does that result
match what you were expecting? You ONLY look
at the output, not what happens within each step
of the application
• There are benefits and drawbacks to Black Box
Testing
1/28/2019 UNIVERSITY OF WISCONSIN 35

36. White Box Testing
• White-box testing (also known as clear box
testing, glass box testing, transparent box testing,
and structural testing) is a method of testing
software that tests internal structures or
workings of an application, as opposed to its
functionality (i.e. black-box testing). In white-box
testing an internal perspective of the system, as
well as programming skills, are used to design
test cases
1/28/2019 UNIVERSITY OF WISCONSIN 36

37. Regression Testing
• Is a type of software testing which verifies that
software which was previously developed and
tested still performs the same way after it was
changed or interfaced with other software.
Changes may include software enhancements,
patches, configuration changes, etc. During
regression testing, new software bugs or
regressions may be uncovered.
1/28/2019 UNIVERSITY OF WISCONSIN 37

38. Test Automation
• Is the use of special software (separate from the
software being tested) to control the execution of
tests and the comparison of actual outcomes with
predicted outcomes.[1] Test automation can
automate some repetitive but necessary tasks in a
formalized testing process already in place, or
perform additional testing that would be difficult
to do manually.
1/28/2019 UNIVERSITY OF WISCONSIN 38

39. User Acceptance Testing
• UAT consists of a process of verifying that a
solution works for the user. It is not system
testing (ensuring software does not crash and
meets documented requirements), but rather
ensures that the solution will work for the user
(i.e., tests that the user accepts the solution);
software vendors often refer to this as "Beta
testing".
1/28/2019 UNIVERSITY OF WISCONSIN 39

40. Software Performance
Testing
• Is in general, a testing practice performed to
determine how a system performs in terms of
responsiveness and stability under a particular
workload. It can also serve to investigate,
measure, validate or verify other quality
attributes of the system, such as scalability,
reliability and resource usage.
1/28/2019 UNIVERSITY OF WISCONSIN 40

41. SDLC Training and Transition
• Once a system has been stabilized through adequate
testing, the SDLC ensures that proper training on the
system is performed or documented before
transitioning the system to its support staff and end
users.
• Training usually covers operational training for those
people who will be responsible for supporting the
system as well as training for those end users who
will be using the system after its delivery to a
production operating environment.
1/28/2019 UNIVERSITY OF WISCONSIN 41

42. Operations and Maintenance
• Release
• Installation and activation
• Deactivation
• Uninstallation
• Update
• Automated Update
• Version tracking
• Adaptation
1/28/2019 UNIVERSITY OF WISCONSIN 42

43. SDLC Evaluation
• The final phase of the SDLC is to measure the
effectiveness of the system and evaluate potential
enhancements.
1/28/2019 UNIVERSITY OF WISCONSIN 43

44. Strengths and Weaknesses of SDLC
1/28/2019 UNIVERSITY OF WISCONSIN 44
Strengths Weaknesses
Control Increased development time
Monitor large projects Increased development cost
Detailed steps Systems must be defined up front
Evaluate costs and completion targets Rigidity
Documentation
Hard to estimate costs, project
overruns
Well defined user input User input is sometimes limited
Ease of maintenance
Development and design standards
Tolerates changes in MIS staffing

45. 1/28/2019 UNIVERSITY OF WISCONSIN 45