This document discusses various system development methodologies and automated tools. It describes methodology approaches like waterfall, parallel development, rapid application development including phased development, prototyping, and agile development using extreme programming. Key criteria for selecting a methodology include the clarity of requirements, technology familiarity, complexity, reliability, schedules, and visibility. The document also outlines computer-aided software engineering tools that automate and standardize development processes, improving quality, documentation, and project management while simplifying maintenance.

1. Chapter 2:
System Development
Methodologies &
Automated Systems
1

2. Learning Objectives
Understand the evolution of system
development methodologies
Understand the use of CASE Tools in System
Development
2

3. System Development
Methodologies
Methodology: a formalized approach to
implementing the SDLC
A set of sequential stages
Categories
Process oriented
Data centered
Object-oriented
Structured
Rapid action development
Agile development 3

4. Classes of Methodologies
Structured Development
Waterfall Development
Parallel Development
Rapid Application Development
Phased
Prototyping
Agile Development
eXtreme Programming (XP)
4

5. Example:
Making a Simple Lunch
5

6. Structured Development:
Waterfall Development
The original structured design methodology (that is still
used today)
The analysts and users proceed in sequence from one
phase to the next
The key deliverables for each phase are typically very long
(often hundreds of pages in length) and are presented to
the project sponsor for approval as the project moves
from phase to phase.
6

7. Once the sponsor approves the work that was conducted
for a phase, the phase ends and the next one begins.
This methodology is referred to as waterfall development
because it moves forward from phase to phase in the
same manner as a waterfall.
While it is possible to go backward in the SDLC (e.g.,
from design back to analysis), it is extremely difficult.
7

8. 8

9. Pros & Cons
Pros Cons
Identifies system requirements
long before programming
begins
The design must
be completely specified before
programming begins
Minimizes changes to the
requirements as the project
proceeds
A long time elapses between
the completion of the system
proposal in the analysis phase
and the delivery of the system
(usually many months or
years)
9

10. Structured Development:
Parallel Development
The parallel development methodology attempts to
address the problem of long delays between the analysis
phase and the delivery of the system.
Instead of doing design and implementation in sequence,
it performs a general design for the whole system and
then divides the project into a series of distinct
subprojects that can be designed and implemented in
parallel.
 Once all subprojects are complete, there is a final
integration of the separate pieces, and the system is
delivered
10

11. 11

12. Pros & Cons
Pros Cons
It can reduce the schedule
time to deliver a system
Too many documents
Less chance of changes in the
business environment causing
rework
adds a new problem
12

13. Rapid Application
Development
A second category of methodologies includes rapid
application development (RAD)–based methodologies
that emerged in the 1990s.
RAD-based methodologies attempt to address both
weaknesses of structured design methodologies by
adjusting the SDLC phases to get some part of the system
developed quickly and into the hands of the users.
Users can better understand the system and suggest
revisions that bring the system closer to what is needed.
13

14. Most RAD-based methodologies recommend that
analysts use special techniques and computer tools to
speed up the analysis, design, and implementation
phases,
CASE tools
 Joint Application Design (JAD) sessions
Fourth generation/visual programming languages that
simplify and speed-up programming (e.g., Visual Basic),
code generators that automatically produce programs from
design specifications.
It is the combination of the changed SDLC phases and the
use of these tools and techniques that improve the speed
and quality of systems development.
14

15. RAD: Phased Development
A phased development–based methodology breaks the
overall system into a series of versions that are developed
sequentially.
The analysis phase identifies the overall system concept,
and the project team, users, and system sponsor then
categorize the requirements into a series of versions.
The most important and fundamental requirements are
bundled into the first version of the system.
The analysis phase then leads into design and
implementation, but only with the set of requirements
identified for version 1.
15

16. Once version 1 is implemented, work begins on version
2. Additional analysis is performed based on the
previously identified requirements and combined with
new ideas and issues that arose from the users’
experience with version 1.
Version 2 then is designed and implemented, and work
immediately begins on the next version. This process
continues until the system is complete or is no longer in
use.
16

17. 17

18. Pros & Cons
Pros Cons
Users Get a System
To Use Quickly
Users Work with a
System that is
Intentionally
Incomplete
Users Can Identify
Additional Needs
For Later Versions
18

19. RAD: Prototyping
A prototyping-based methodology performs the analysis,
design, and implementation phases concurrently, and all
three phases are performed repeatedly in a cycle until the
system is completed.
the basics of analysis and design are performed, and work
immediately begins on a system prototype, a “quick-and
dirty” program that provides a minimal amount of
features.
First prototype is usually the first part of the system that
the user will use.
19

20. 1st
Prototype- shown to the users and project sponsor
who provide comments :-
re-analyze, re-design, and re-implement a second
prototype that provides a few more features.
This process continues in a cycle until the analysts, users,
and sponsor agree that the prototype provides enough
functionality to be installed and used in the organization.
After the prototype (now called the system) is installed,
refinement occurs until it is accepted as the new system
20

21. 21

22. Pros & Cons
Pros Cons
Users Interact with
Prototype Very Quickly Tendency to do
Superficial Analysis (Careful Analysis)
Initial Design
Decisions May
Be Poor
Users Can Identify
Needed Changes
And Refine Real
Requirements
22

23. RAD: Throwaway Prototyping
Similar to prototyping-based methodologies in that they
include the development of prototypes.
However throwaway prototypes are done at a different
point in the SDLC.
These prototypes are used for a very different purpose
than ones previously discussed, and they have a very
different appearance.
The throwaway prototyping-based methodologies have a
relatively thorough analysis phase that is used to gather
information and to develop ideas for the system concept.
23

24. 24

25. Each of these issues is examined by analyzing, designing,
and building a design prototype.
A design prototype is not a working system. It is a
product that represents a part of the system that needs
additional refinement, and it only contains enough detail
to enable users to understand the issues under
consideration.
A system that is developed using this type of
methodology probably relies on several design prototypes
during the analysis and design phases.
25

26. Each of the prototypes is used to minimize the risk
associated with the system by confirming that important
issues are understood before the real system is built.
Once the issues are resolved, the project moves into
design and implementation.
 At this point, the design prototypes are thrown away,
which is an important difference between these
methodologies and prototyping methodologies, in which
the prototypes evolve into the final system.
26

27. Pros & Cons
Pros Cons
Risks are Minimized
May Take Longer
Than Prototyping
Important Issues are
Understood Before the
Real System is Built
27

28. Agile Development
These programming-centric methodologies have few
rules and practices, all of which are fairly easy to follow.
They focus on streamlining the SDLC by eliminating much
of the modeling and documentation overhead, and the
time spent on those tasks
Projects emphasize simple, iterative application
development.
Example: extreme programming (XP)
28

29. Agile Development:
Extreme Programming
Is founded on four core values: communication, simplicity,
feedback, and courage.
These four values provide a foundation on which XP
developers use to create any system.
First, the developers must provide rapid feedback to the
end users on a continuous basis.
Second, XP requires developers to follow the KISS
principle.
.
29

30. Third, developers must make incremental changes to
grow the system and they must not only accept change,
they must embrace change.
Fourth, developers must have a quality first mentality. XP
also supports team members in developing their own
skills
30

31. XP Key Principles
Three of the key principles that XP uses to create
successful systems are
Continuous testing,
simple coding performed by pairs of developers, and
close interactions with end users to build systems very
quickly.
An XP project begins with user stories that describe what
the system needs to do.
Then, programmers code in small, simple modules and
test to meet those needs.
31

32. Users are required to be available to clear up questions
and issues as they arise.
XP projects deliver results sooner than even the RAD
approaches, and they rarely get bogged down in
gathering requirements for the system.
32

33. Pros & Cons
Pros Cons
Fast Delivery of Results Requires Discipline
Works Well in Projects
With Undefined or
Changing Requirements
Works Best in
Small Projects
Requires Much
User Input
33

34. Selecting the Appropriate
Development Methodology
1. Clarity of User Requirements
2. Familiarity of Technology
3. System Complexity
4. System Reliability
5. Short Time Schedules
6. Schedule Visibility
34

35. Which Methodology to Use?
35

36. Automated Tools for System
Development
Computer-aided software engineering (CASE) is a
category of software that automates all or part of the
development process.
Some CASE software packages are primarily used during
the analysis phase to create integrated diagrams of the
system and to store information regarding the system
components (often called upper CASE).
Whereas others are design-phase tools that create the
diagrams and then generate code for database tables and
system functionality (often called lower CASE).
36

37. Objectives of CASE
Improve quality of systems developed
 Increase speed of development and design
 Ease and improve testing process through automated checking
 Improve integration of development activities via common methodologies
 Improve quality and completeness of documentation
 Help standardize the development process
 Improve project management
 Simply program maintenance
 Promote reusability
 Improve software portability 37

38. Benefits of CASE
The benefits to using CASE are numerous.
Tasks are much faster to complete and alter
Development information is centralized
Information is illustrated through diagrams, which
typically are easier to understand.
 CASE can reduce maintenance costs
Improve software quality, and enforce discipline, and
some project teams even use CASE to assess the
magnitude of changes to the project.
38

39. The central component of any CASE tool is the CASE
repository, otherwise known as the information repository
or data dictionary.
The CASE repository stores the diagrams and other
project information, such as screen and report designs,
and it keeps track of how the diagrams fit together.
For example, most CASE tools will warn you if you place
a field on a screen design that doesn’t exist in your data
model.
 As the project evolves, project team members perform
their tasks using CASE.
39

40. Summary
There are several methodologies that can be use to
develop system:-
Waterfall
Parallel
Phased Development
Prototyping
XP
Criteria for selecting the appropriate methodologies:-
Clarity of user requirements
Familiarity with technology
40

41. System complexity
System reliability
Short Time schedules
Schedule Visibility
Automated Tools System Development
CASE Tools
Objectives of CASE Tools
Benefits of CASE
41