System Developement Cycle (SDLC)

1. FOUNDATIONS FOR SYSTEMS
DEVELOPMENT
1. The Systems Development Environment
2. The Origins of Software
3. Managing the Information Systems Project
1

2. LEARNING OBJECTIVES
 Define information systems analysis and design.
 Describe the information systems development life cycle
(SDLC).
 Explain Rapid Application Development (RAD) and
Computer-aided Software Engineering (CASE) tools.
 Describe Agile Methodologies and eXtreme Programming.
 Explain object-oriented analysis and design and the
Rational Unified Process (RUP).
2

3. INTRODUCTION
 Information Systems Analysis and Design
 Complex organizational process
 Used to develop and maintain computer-based information
systems
 Used by a team of business and systems professionals
3

4. INTRODUCTION (CONT.)
4
FIGURE 1-1 An organizational approach to systems analysis and
design is driven by methodologies, techniques, and tools

5. INTRODUCTION (CONT.)
 Application Software
 Computer software designed to support organizational
functions or processes
 Systems Analyst
 Organizational role most responsible for analysis and
design of information systems
5

6. A MODERN APPROACH TO SYSTEMS ANALYSIS
AND DESIGN
 1950s: focus on efficient automation of existing
processes
 1960s: advent of procedural third generation languages
(3GL) faster and more reliable computers
 1970s: system development becomes more like an
engineering discipline
6

7. A MODERN APPROACH TO SYSTEMS ANALYSIS
AND DESIGN (CONT.)
 1980s: major breakthrough with 4GL, CASE tools, object-
oriented methods
 1990s: focus on system integration, GUI applications,
client/server platforms, Internet
 The new century: Web application development, wireless
PDAs and smart phones, component-based applications,
application service providers (ASP)
7

8. DEVELOPING INFORMATION SYSTEMS
 System Development Methodology is a standard
process followed in an organization to conduct all the
steps necessary to analyze, design, implement, and
maintain information systems.
8

9. 9

10. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
 Traditional methodology used to develop,
maintain, and replace information systems
 Phases in SDLC:
 Planning
 Analysis
 Design
 Implementation
 Maintenance
10

11. STANDARD AND EVOLUTIONARY VIEWS OF SDLC
11
FIGURE 1-3 Evolutionary model
FIGURE 1-2
Systems development life cycle

12. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
(CONT.)
 Planning – an organization’s total information system
needs are identified, analyzed, prioritized, and arranged
 Analysis – system requirements are studied and
structured
 Design – a description of the recommended solution is
converted into logical and then physical system
specifications
12

13. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
(CONT.)
 Logical design – all functional features of the system
chosen for development in analysis are described
independently of any computer platform
 Physical design – the logical specifications of the
system from logical design are transformed into the
technology-specific details from which all programming
and system construction can be accomplished
13

14. SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
(CONT.)
 Implementation – the information system is coded,
tested, installed and supported in the organization
 Maintenance – an information system is systematically
repaired and improved
14

15. 15

16. THE HEART OF THE SYSTEMS DEVELOPMENT PROCESS
FIGURE 1-5
The heart of systems development
Current practice combines analysis, design, and implementation
into a single iterative and parallel process of activities.
FIGURE 1-4
Analysis–design–code–test loop

17. WATERFALL MODEL
17
FIGURE 1-6
Traditional waterfall model
1. Project is divided into sequential phases, with some
overlap and splashback acceptable between phases.
2. Emphasis is on planning, time schedules, target
dates, budgets and implementation of an entire system
at one time.
3. Tight control is maintained over the life of the project
through the use of extensive written documentation, as
well as through formal reviews and approval/signoff by
the user and information technology management
occurring at the end of most phases before beginning
the next phase.

18. PROBLEMS WITH WATERFALL APPROACH
 Feedback ignored, milestones lock in design specs
even when conditions change
 Limited user involvement (only in requirements
phase)
 Too much focus on milestone deadlines of SDLC
phases to the detriment of sound development
practices
18

19. SOMETHING TO PONDER..
 Based on the explanation and problems in Waterfall
model discussed earlier, what do you think would
be the strengths, weaknesses and suitable projects
using Waterfall approach?
19

20. DIFFERENT APPROACHES TO IMPROVING
DEVELOPMENT
Rapid Application Development (RAD)
CASE Tools
Agile Methodologies
eXtreme Programming
20

21. RAPID APPLICATION DEVELOPMENT (RAD)
21
 Decreases design and
implementation time
 Involves: extensive user
involvement, prototyping,
integrated CASE tools, code
generators
 More focus on user interface
and system function, less on
detailed business analysis and
system performance
FIGURE 1-7
RAD life cycle

22. COMPUTER-AIDED SOFTWARE ENGINEERING
(CASE) TOOLS
 Diagramming tools enable graphical representation.
 Computer displays and report generators help prototype how
systems “look and feel”.
 IBM’s Rational products are the best known CASE tools.
 Analysis tools automatically check for consistency in diagrams,
forms, and reports.
 A central repository provides integrated storage of diagrams,
reports, and project management specifications.
 Documentation generators standardize technical and user
documentation.
 Code generators enable automatic generation of programs and
database code directly from design documents, diagrams, forms,
and reports.
22

23. CASE TOOLS (CONT.)
23
FIGURE 1-8
Screen shot of ArgoUML,
an open source CASE tool
(Source: http://argouml.tigris.org/)

24. CASE TOOLS (CONT.)
24

25. AGILE METHODOLOGIES
 Motivated by recognition of software development
as fluid, unpredictable, and dynamic
 Three key principles
 Adaptive rather than predictive
 Emphasize people rather than roles
 Self-adaptive processes
25

26. 26
The Agile Methodologies
group argues that software
development methodologies
adapted from engineering
generally do not fit with real-
world software development.

27. WHEN TO USE AGILE METHODOLOGIES
 If your project involves:
 Unpredictable or dynamic requirements
 Responsible and motivated developers
 Customers who understand the process and will get involved
27

28. 28

29. EXTREME PROGRAMMING
29
 Short, incremental
development cycles
 Automated tests
 Two-person programming
teams
 Coding, testing, listening,
designing
 Coding and testing operate
together
 Advantages:
 Communication between
developers
 High level of productivity
 High-quality code

30. OBJECT-ORIENTED ANALYSIS AND DESIGN
(OOAD)
 Based on objects rather than data or processes
 Object: a structure encapsulating attributes and behaviors of a
real-world entity
 Object class: a logical grouping of objects sharing the same
attributes and behaviors
 Inheritance: hierarchical arrangement of classes enable
subclasses to inherit properties of superclasses
30

31. RATIONAL UNIFIED PROCESS (RUP)
31
 An object-oriented
systems development
methodology
 Establishes four phase
of development:
inception, elaboration,
construction, and
transition
 Each phase is
organized into a
number of separate
iterations.
FIGURE 1-9
Phases of OOSAD-based development

32. OUR APPROACH TO SYSTEMS DEVELOPMENT
 The SDLC is an organizing and guiding principle in
this book.
 We may construct artificial boundaries or artificially
separate activities and processes for learning
purposes.
 Our intent is to help you understand all the pieces
and how to assemble them.
32

33. SAMPLE QUESTIONS
1. Systems development life cycle (SDLC) methodology
is a standard process in an organization to conduct
systematic process in an organization for software
development. Describe in detail phases in SDLC.
Support your answer with appropriate diagram. (10
marks) Answer & Answer
2. Traditional SDLC was famously criticized for its
rigidity. State and explain THREE (3) approaches that
you think might be helpful for analysts to improve the
development. Justify your answer with appropriate
example(s) for each approach.
(9 marks) Answer 33

34. SUMMARY
 In this chapter you learned how to:
 Define information systems analysis and design.
 Describe the information Systems Development Life
Cycle (SDLC).
 Explain Rapid Application Development (RAD),
prototyping, Computer Aided Software Engineering
(CASE), and Service-Oriented Architecture (SOA).
 Describe agile methodologies and eXtreme
programming.
 Explain Object-Oriented Analysis and Design (OOAD)
and the Rational Unified Process (RUP).
34

35. 35

36. Chapter 2
The Origins of Software
36

37. LEARNING OBJECTIVES
 Explain outsourcing.
 Describe six different sources of software.
 Discuss how to evaluate off-the-shelf software.
 Explain reuse and its role in software development.
37

38. INTRODUCTION
 There are various sources of software for organizations.
 Most of a corporation’s application software is created by
external sources.
 Much in-house coding involves making components work
together.
 There are criteria to evaluate software from different
sources.
38

39. SYSTEMS ACQUISITION: OUTSOURCING
 Outsourcing: Turning over responsibility of some or all
of an organization’s information systems applications
and operations to an outside firm
 Outsourcing Example
 Shell Oil outsource spending: $3.2 billion (2008)
 Shell’s outsourcing vendors (2008-2011): EDS, T-Systems,
AT&T, IBM, Logica, Wipro, Accenture
39

40. OUTSOURCING (CONT.)
 Reasons to outsource
 Cost-effectiveness
 Take advantage of economies of scale
 Make up for lack of in-house knowledge
 Free up internal resources
 Reduce time to market
 Increase process efficiencies
 System development is a non-core activity for the organization
40

41. SOURCES OF SOFTWARE
 Information technology services firm
 Packaged software producers
 Enterprise-wide solutions
 Enterprise Resource Planning (ERP)
 Cloud computing
 Open source software
 In-house developers
41

42. SOURCES OF SOFTWARE (CONT.)
42
FIGURE 2-1
Sources of Application Software

43. SOURCES OF SOFTWARE (CONT.)
43

44. INFORMATION TECHNOLOGY (IT) SERVICES FIRMS
 Help companies develop custom information
systems for internal use
 Develop, host, and run applications for customers
 Provide other services
44

45. PACKAGED SOFTWARE PRODUCERS
45
 Serve many market
segments
 Provide software
ranging from broad-
based packages (i.e.
general ledger) to
niche packages (i.e.
day care management)
 Pre-packaged, off-the-
shelf software
 Software runs on all
size computers, from
microcomputers to
large mainframes.
 Prepackaged software
is off-the-shelf, turnkey
software (i.e. not
customizable).
 Off-the-shelf software,
at best, meets 70% of
organizations’ needs.

46. PREPACKAGED SOFTWARE
46
Figure 2-2 Microsoft Project (Source: Microsoft Corporation.)

47. ENTERPRISE SOLUTIONS SOFTWARE
 Enterprise Resource Planning (ERP) systems
integrate individual traditional business functions into
modules enabling a single seamless transaction to
cut across functional boundaries.
 SAP AG is the leading vendor of ERP systems.
47

48. ENTERPRISE SOLUTIONS SOFTWARE (CONT.)
48
Figure 2-3 SAP’s Business ByDesign, a product designed for medium sized
companies.
(Source: www.sap.com/usa/solutions/Sme/ Businessbydesign/Flash/bsm/A1S.html.
© Copyright SAP AG. All rights reserved.)

49. CLOUD COMPUTING
 The provision of computing resources, including
applications, over the Internet, so customers do not
have to invest in the computing infrastructure needed
to run and maintain the resources
 Examples:
 Google Drive – users store what they want on servers
 Salesforce.com – online customer relationship
management (CRM) software
 Microsoft Azure platform
 Amazon.com cloud infrastructure and services
49

50. CLOUD COMPUTING (CONT.)
 Heavy growth predicted
 Benefits:
 Free internal IT staff
 Faster access to application than via internal development
 Lower cost than internal development
 Concerns
 Security
 Reliability
 Regulation compliance
50

51. OPEN SOURCE SOFTWARE
 Freely available including source code
 Developed by a community of interested people
 Performs the same functions as commercial software
 Examples: Linux, mySQL, Firefox
 How to make money?
 Provide maintenance/services
 Sell a more featured version of the free software
51

52. IN-HOUSE DEVELOPMENT
 If sufficient system development expertise with the
chosen platform exists in-house, then some or all of
the system can be developed by the organization’s
own staff.
 Hybrid solutions involving some purchased and some
in-house components are common.
52

53. SOURCES OF SOFTWARE COMPONENTS
53

54. SELECTING OFF-THE-SHELF SOFTWARE
 Cost: comparing the cost of developing the same system in-
house with the cost of purchasing or licensing the software
package
 Functionality: the tasks that the software can perform and
the mandatory, essential, and desired system features
 Vendor support: whether and how much support the
vendor can provide and at what cost
 Viability of vendor: can vendor continue to adapt/update
software to changes in systems software and hardware
54

55. SELECTING OFF-THE-SHELF SOFTWARE (CONT.)
 Flexibility: the ease with which software is customized
 Documentation: understandable and up-to-date user’s
manual and technical documentation
 Response time: how long it takes the software package
to respond to the user’s requests in an interactive
session
 Ease of installation: a measure of the difficulty of
loading the software and making it operational
55

56. VALIDATING PURCHASED SOFTWARE
INFORMATION
 Use a variety of information sources:
 Collect information from vendor
 Software documentation
 Technical marketing literature
56

57. REQUEST FOR PROPOSAL (RFP)
 A request for proposal (RFP) is a document
provided to vendors to ask them to propose
hardware and system software that will meet the
requirements of a new system.
 Sometimes called a Request For Quote (RFQ)
 Analyst selects best candidates based on:
 vendor bids
 a variety of information sources
57

58. INFORMATION SOURCES FOR RFP
 Vendor’s proposal
 Running software through a series of tests
 Feedback from other users of the vendor’s product
 Independent software testing services
 Articles in trade publications
58

59. REUSE
 The use of previously written software resources,
especially objects and components, in new applications
 Commonly applied to two different development
technologies:
 Object-oriented development
 Component-based development
59

60. REUSE (CONT.)
 Object-oriented development
 Object class encapsulates data and behavior of common
organizational entities (e.g. employees)
 Component-based development
 Components can be as small as objects or as large as
pieces of software that handle single business functions
 Object-oriented development reuse is the use of object classes
in more than one application (e.g. Employee).
 Component-based development reuse is the assembly of an
application from many different components at many different
levels of complexity and size (e.g. Currency conversion).
60

61. COSTS AND BENEFITS OF REUSE
61
FIGURE 2-5
Investments necessary to achieve reusable components
(Source: Royce, Walker, Software Project Management: A Unified Framework, 1st
ed.,©1998. Reprinted and Electronically reproduced by permission of Pearson
Education, Inc. Upper Saddle River, New Jersey.)

62. APPROACHES TO REUSE
 Ad-hoc: individuals are free to find or develop
reusable assets on their own
 Facilitated: developers are encouraged to practice
reuse
 Managed: the development, sharing, and adoption
of reusable assets is mandated
 Designed: assets mandated for reuse as they are
being designed for specific applications
62

63. APPROACHES TO REUSE (CONT.)
63

64. SAMPLE QUESTIONS
Compare and contrast the following terms:
1. Outsourcing and Reuse.
(6 marks)
2. Facilitated Reuse and Designed Reuse.
(6 marks)
64

65. SUMMARY
 In this chapter you learned how to:
 Explain outsourcing.
 Describe six different sources of software.
 Discuss how to evaluate off-the-shelf software.
 Explain reuse and its role in software development.
65

66. Chapter 3
Managing the Information
Systems Project

67. LEARNING OBJECTIVES
 Explain the process of managing an information systems
project.
 Describe the skills required to be an effective project manager.
 List and describe the skills and activities of a project manager
during project initiation, project planning, project execution,
and project closedown.
 Explain what is meant by critical path scheduling and describe
the process of creating Gantt charts and network diagrams.
 Explain how commercial project management software
packages can be used to assist in representing and managing
project schedules.
67

68. INTRODUCTION
 Project management (PM) may be the most important
aspect of systems development.
 Effective PM helps to ensure
 The meeting of customer expectations.
 The satisfying of budget and time constraints.
 The nature of projects has changed from custom
development to implementing packaged software and
data warehousing.
 PM skills are difficult and important to learn.
68

69. MANAGING THE INFORMATION SYSTEMS PROJECT
 Project
 A planned undertaking of related activities to reach an
objective that has a beginning and an end
 Project management
 A controlled process of initiating, planning, executing, and
closing down a project
 Project manager
 A systems analyst with a diverse set of skills—management,
leadership, technical, conflict management, and customer
relationship—who is responsible for initiating, planning,
executing, and closing down a project
 Deliverable
 The end product of an SDLC phase
69

70. DECIDING ON SYSTEMS PROJECTS
 System Service Request (SSR)
 A standard form for requesting or proposing systems
development work within an organization
 Feasibility study
 A study that determines whether a requested system makes
economic and operational sense for an organization
70

71. 71
FIGURE 3-2
System Service Request for
Purchasing Fulfillment System with
name and contact information of
the person requesting the system,
a statement of the problem, and
the name and contact information
of the liaison and sponsor

72. PROJECT MANAGEMENT ACTIVITIES
72
FIGURE 3-4
A project manager juggles
numerous activities

73. PHASES OF PROJECT MANAGEMENT PROCESS
 Phase 1: Initiation
 Phase 2: Planning
 Phase 3: Execution
 Phase 4: Closedown
73

74. PM PHASE 1: PROJECT INITIATION
 Assess size, scope and complexity, and
establish procedures.
 Establish:
 Initiation team
 Relationship with customer
 Project initiation plan
 Management procedures
 Project management environment and workbook
 Project charter
74

75. 75
FIGURE 3-6
The project workbook for
the Purchase Fulfillment
System project contains
nine key documents in
both hard-copy and
electronic form.

76. PROJECT CHARTER
 A short document prepared for the customer
describing project deliverables and outlining the work
required to complete the project
 Elements:
 Title and authorization date
 Project manager name and contact information
 Customer name and contact information
 Project start and completion dates
 Key stakeholders, roles, responsibilities
 Project objectives and description
 Key assumptions
 Signatures of stakeholders
76

77. PM PHASE 2: PROJECT PLANNING
77
1. Describing Project Scope,
Alternatives, and Feasibility
2. Dividing the Project into
Manageable Tasks
3. Estimating Resources and
Creating a Resource Plan
4. Developing a Preliminary
Schedule
5. Developing a
Communication Plan
6. Determining Project
Standards and Procedures
7. Identifying and Assessing
Risk
8. Creating a Preliminary
Budget
9. Developing a Project
Scope Statement
10. Setting a Baseline Project
Plan
Define clear, discrete activities and the work needed to
complete each activity. Tasks include:

78. PLANNING DETAIL
78
FIGURE 3-8
Level of project
planning detail should
be high in the short
term, with less detail
as time goes on.

79. PROJECT SCOPE, ALTERNATIVES, AND
FEASIBILITY
 What problem or opportunity does the project address?
 What are the quantifiable results to be achieved?
 What needs to be done?
 How will success be measured?
 How will we know when we are finished?
79

80. DIVIDING PROJECT INTO MANAGEABLE TASKS
 Work Breakdown Structure (WBS)
 Division of project into manageable and logically
ordered tasks and subtasks
 Scheduling Diagrams
 Gantt chart: horizontal bars represent task durations
 Network diagram: boxes and links represent task
dependencies
80

81. DEVELOPING A PRELIMINARY SCHEDULE
81
FIGURE 3-10
Gantt chart showing project tasks, duration times for those tasks, and predecessors
WBS Gantt Chart

82. SCHEDULING DIAGRAMS NETWORK DIAGRAM
82
FIGURE 3-13
A network diagram illustrating tasks with rectangles (or ovals) and the
relationships and sequences of those activities with arrows (Source:
Microsoft Corporation.)

83. DEVELOPING A PRELIMINARY BUDGET
83
Spreadsheet
software is
good for this.
FIGURE 3-15
A financial cost and
benefit analysis for a
systems development
project (Source:
Microsoft Corporation.)

84. DEVELOPING A COMMUNICATION PLAN
 Who are stakeholders?
 What information does each stakeholder need?
 When should information be produced?
 What are sources of information?
 Who will collect, store and validate info?
 Who will organize and document info?
 Who is the contact person for each stakeholder?
 What is the appropriate/best format for info?
 What communication medium should be used? 84

85. SETTING A BASELINE PROJECT PLAN
 A Baseline Project Plan provides an estimate of
the project’s tasks and resource requirements and
is used to guide the next project phase—execution.
As new information is acquired during project
execution, the baseline plan will continue to be
updated.
85

86. PM PHASE 3: PROJECT EXECUTION
 Plans created in prior phases are put into action.
 Actions
 Execute baseline project plan.
 Monitor progress against baseline plan.
 Manage changes in baseline plan.
 Maintain project workbook.
 Communicate project status.
86

87. MONITORING PROGRESS WITH A GANTT CHART
87
Red bars indicate critical path; lines through bars indicate
percent complete.
FIGURE 3-17
Gantt chart with tasks 3 and 7 completed and task 8 partially completed
(Source: Microsoft Corporation.)

88. COMMUNICATION METHODS
88

89. PM PHASE 4: PROJECT CLOSEDOWN
 Bring the project to an end.
 Actions
 Close down the project.
 Conduct post-project reviews.
 Close the customer contract.
89

90. REPRESENTING AND SCHEDULING PROJECT
PLANS
 Gantt Charts
 Network Diagrams
 PERT Calculations
 Critical Path Scheduling
 Project Management Software
90

91. GANTT CHARTS VS. NETWORK DIAGRAMS
 Gantt charts
 Show task durations.
 Show time overlap.
 Show slack time in duration.
 Network diagrams
 Show task dependencies.
 Do not show time overlap, but show parallelism.
 Show slack time in boxes.
91

92. GANTT CHARTS VS. NETWORK DIAGRAMS
(CONT.)
92
Figure 3-19
Graphical diagrams that depict project
plans
(a) A Gantt chart
(b) A network diagram
(Source: Microsoft Corporation.)

93. GANTT CHARTS VS. NETWORK DIAGRAMS
(CONT.)
93
Figure 3-21
A network diagram showing activities (represented by
circles) and sequence of those activities (represented by
arrows)

94. ESTIMATING TASK DURATION
 PERT: Program Evaluation Review Technique
 Technique that uses optimistic (o), pessimistic (p), and
realistic (r) time estimates to determine expected task
duration
 Formula for Estimated Time:
 ET = (o + 4r + p)/6
94

95. EXAMPLE PERT ANALYSIS
95
FIGURE 3-22
Estimated time calculations for the SPTS project

96. CRITICAL PATH SCHEDULING
 A scheduling technique whose order and duration
of a sequence of task activities directly affect the
completion
 Critical path: the shortest time in which a project
can be completed
 Slack time: the time an activity can be delayed
without delaying the project
96

97. CRITICAL PATH EXAMPLE
(DEPENDENCIES BETWEEN TASKS)
97
PRECEDING ACTIVITIES
indicate the activities that
must be completed before
the specified activity can
begin.
FIGURE 3-23 Sequence of Activities within the SPTS project

98. CRITICAL PATH EXAMPLE (CONT.)
98
Figure 3-24
Gantt chart that illustrates the sequence and duration of each
activity of the SPTS project
(Source: Microsoft Corporation.)

99. FIGURE 3-25
A network diagram that illustrates the activities (circles) and the sequence
(arrows) of those activities
CRITICAL PATH EXAMPLE (CONT.)
99
Network diagram
shows dependencies

100. DETERMINING THE CRITICAL PATH
 Calculate the earliest possible completion time for
each activity by summing the activity times in the
longest path to the activity. This gives total expected
project time.
 Calculate the latest possible completion time for each
activity by subtracting the activity times in the path
following the activity from the total expected time.
This gives slack time for activities.
 Critical path contains no activities with slack time.
100

101. CRITICAL PATH CALCULATION
101
Early and late time calculations are determined and critical path
established. (Note: Activity #5 can begin late without affecting
project completion time.)
FIGURE 3-26
A network diagram for the SPTS project showing estimated times for each
activity and the earliest and latest expected completion time for each activity

102. CRITICAL PATH CALCULATION (CONT.)
102
Note the slack time in Activity #5.
FIGURE 3-27
Activity slack time calculations for the SPTS project; all activities except
number 5 are on the critical path

103. USING PROJECT MANAGEMENT SOFTWARE
 Many powerful software tools exist for assisting with
project management.
 Example: Microsoft Project can help with
 Entering project start or end date.
 Establishing tasks and task dependencies.
 Viewing project information as Gantt or Network
diagrams.
103

104. PROJECT START DATE
104
FIGURE 3-28
Establishing a project starting date in Microsoft Project for Windows
(Source: Microsoft Corporation.)

105. ENTERING TASKS
105
FIGURE 3-29
Entering tasks and assigning task relationships in Microsoft project
for Windows (Source: Microsoft Corporation.)

106. VIEWING NETWORK DIAGRAM
106
Hexagon shape indicates a
milestone.
FIGURE 3-30
Viewing project
information as a
network diagram
in Microsoft
Project for
Windows
(Source:
Microsoft
Corporation.)
Red boxes and arrows indicate
critical path (no slack).

107. VIEWING GANTT CHART
107
Black line at top indicates a summary activity (composed of subtasks).
Diamond shape indicates a milestone.
FIGURE 3-31
Gantt chart showing progress of activities (right frame) versus planned
activities (left frame)

108. SUMMARY
 In this chapter you learned how to:
 Explain the process of managing an information
systems project.
 Describe the skills required to be an effective project
manager.
 List and describe the skills and activities of a project
manager during project initiation, project planning,
project execution, and project closedown.
 Explain what is meant by critical path scheduling and
describe the process of creating Gantt charts and
network diagrams.
 Explain how commercial project management software
packages can be used to assist in representing and
managing project schedules. 108