Section 3: Lifecycle Management: Project Management Business Application Development Application Development

CISA Examination Preparation Course
Section 3: Lifecycle Management

Project Management
Business Application Development
Application Development
© 2009
2017 Global
PreciseKnowledge Training
Thinking TCT. LLC.reserved.
All rights All rights reserved.
Section Objectives 3-2
After completing this section, you will be

able to:
Describe basic project management

techniques
List basic business application

development methods
Detail application development

© 2009
2017 Global
Introduction 3-3
This section addresses lifecycle management
Primary topics:
Project management
Business application
development
Infrastructure
Acquisition practices
© 2009
2017 Global
Introduction (cont.) 3-4
A CISA candidate should review the following
topics for the exam:
Project-management structure
Formalized steps of the project-management
process: initiating, planning, executing, controlling,
and closing
Identification and definition of the steps of the
system development lifecycle
Alternative approaches to application development,
such as prototyping and agile development
Process-improvement practices
Information systems maintenance practices
© 2009
2017 Global
Project Management 3-5
To discuss project management, one must

first define project management.
Projects are temporary endeavors (actions).
The purpose of a project is to meet a defined

goal of creating a specific product, service,
or result.
Projects are unique, in that when all the

objectives are met, the project is terminated.
© 2009
2017 Global
Projects Have Constraints 3-6
A specific purpose
Projects have unique

attributes and constraints A temporary nature
A primary customer
and/or sponsor
Uncertainty
© 2009
2017 Global
Project Management: Roles and
Responsibility (1) 3-7
The Auditor should:
Play an active part in the project-management process
Auditors should be able to identify person(s)

responsible and key stakeholders:
Senior management: Provides necessary resources to
complete project
Stakeholders: Have a share or an interest in the

project activities
Person, group, or business unit
© 2009
2017 Global
Project steering committee:

Ensures stakeholders’ needs are met
Oversees direction and scope of project
Acts as the project-oversight board
Project sponsor:
Works with the project manager to ensure success
Allocates funding for the project
Project manager:
Are responsible for day-to-day management of the
project team
Project team:
Perform operational tasks within the project
© 2009
2017 Global
Quality Assurance:
Reviews activities of the project team

Ensures that output meets quality
standArds
© 2009
2017 Global
Project Organizational Forms 3-10
Name Description
Formal authority is held by project manager.

Pure project
Team may have a dedicated project work area.
Project manager has NO real authority.
Influence
Functional manager remains in charge.
Project manager is part of the functional organization

Weak matrix
and has little or no authority.
Project manager has some functional authority and

Balanced matrix
shares management duties with functional managers.
In this more expensive model, the project has members
Strong matrix assigned for dedicated tasks offering a greater level of
authority.
© 2009
2017 Global
Project Management Process 3-11
Usually starts with the team working on an
OBS (Object Breakdown Structure) which
defines each component of the project
© 2009
2017 Global
Project Management Practices 3-12
Three constraints of project management:

Scope: Can be better defined by understanding
areas/activities/personnel needed to complete
the project.
Time: Can be better established by building a

project timeline listing each task and specifying a
timeframe for each
Cost: Can be determined by examining lines of

code, number of people in the project team, and
time needed for each phase of the project
© 2009
2017 Global
Software Cost Estimation 3-13
Components that effect the cost of software:
Chosen source code language
Using an obscure or unpopular language will most
likely drive up costs.
Size of the application

Size or complexity of the
application has a bearing on cost.
© 2009
2017 Global
Software Cost Estimation (cont.) 3-14
Project time constraints

Projected completion in one month versus three
months might mean more overtime needs to be paid
or fees for rushed services.
Computer and resource accessibility
If resources are available only during certain times,
output of the project team will likely be reduced.
Project team experience
Learning curve adds cost for inexperienced team
members.
Level of security needed
Very high levels of security controls take additional
time and effort to develop.
© 2009
2017 Global
Software Size Estimates 3-15
Traditional software sizing has been done

by counting SLOC (source lines of code).
Method was developed because early

programs were written in FORTRAN or
other line-oriented languages.
Another method is FPA (function point

analysis).
© 2009
2017 Global
Function Point Analysis (1) 3-16
FPA is based on the number of:
Inputs
Outputs
Interfaces
Files
Queries
© 2009
2017 Global
Function Point Analysis (2) 3-17
The five functional point values are:
Number of user inputs

Number of user outputs
Number of user inquiries
Number of files
Number of external interfaces
© 2009
2017 Global
Scheduling 3-18
Involves linking individual tasks
Two primary methods:

Gantt charts
PERT (Program Evaluation
and Review Technique) charts
© 2009
2017 Global
Gantt Charts 3-19
To schedule activities and monitor progress

Show the start and finish dates of each
element of a project
Show the relationship between activities in a
calendar-like format
Are one of the primary tools used to communicate
project schedule information
Use a baseline to illustrate what will happen if a task
is finished early or late
© 2009
2017 Global
Gantt Charts 3-20
© 2009
2017 Global
PERT (Program Evaluation
and Review Technique) 3-21
Is the preferred tool for estimating time when a

degree of uncertainty exists
Uses a critical-path method that applies a weighed
average duration estimate
Uses probabilistic time estimates for best and
worst time estimates
Uses a three-point time estimate to develop best,
worst, and most likely time estimates
Weighted average is calculated as follows:
PERT weighted average = (optimistic time + 4 × most
likely time + pessimistic time) / 6
© 2009
2017 Global
PERT (cont.) 3-22
Each PERT chart begins

with the first task, then 2
branches out to a
connecting line that 2-5-8 1-2-5
contains three estimates: 5-5-9
Most optimistic time in 1 4
which the task will be
completed. 1-5-7 2-2-6
Most likely time in which
the task will be completed. 3
Worst-case scenario or
longest the task will take
© 2009
2017 Global
Critical Paths 3-23
CPM (critical path methodology) determines what

activities are critical and what the dependencies
are between the various tasks.
CPM is accomplished by:

Compiling a list of tasks required to complete the
project
Determining the time each task will take, from start
to finish
Examining the dependencies between each task
© 2009
2017 Global
Timebox Management 3-24
Used when time is the most critical aspect and

software projects need to be delivered quickly
Used to lock in specifications and prevent creep
© 2009
2017 Global
Project Control and Execution 3-25
Auditors must:
Be aware of any changes
Examine how changes could affect any existing
controls and the overall project
Be concerned with end-user training
When new software products are released, the

users must be trained on:
How the application works?
What type of authentication is required?
How overriding or dual controls work?
© 2009
2017 Global
Closing a Project 3-26
At the conclusion of the project, the project

manager must transfer control to the appropriate
individuals.
Project closing tasks include:

Administrative closure
Release of final product
or service
Update of organizational assets
© 2009
2017 Global
Business Application Development 3-27
The Auditor:
Must know how to manage the development
process so adequate controls are developed
and implemented
Must be able to review information at each step of

the process and provide input on the adequacy of
controls being designed
Is responsible for reporting independently to

management on:
Status of the project
Implementation of controls
© 2009
2017 Global
Life Cycle Phases 3-28
1. Feasibility
2. Requirements
3. Design
4. Development
5. Installation/implementation
6. Post-implementation
© 2009
2017 Global
1. Feasibility 3-29
Project feasibility includes:
Cost of the project
Potential benefits to system users
Payback analysis
Time interval before benefits overtake
continuing costs
© 2009
2017 Global
2. Requirements Definition (1) 3-30
Security controls and checkpoints
Resources identified
Test schedules
Evaluation criteria
Design documentation
© 2009
2017 Global
ERD (Entity Relationship
Diagram) often used Entity
Customer Address
Helps map requirements and
define relationship between Attribute
elements Relation
Order
Basic components of an ERD

An entity Parts Item
A relationship Entity with

Attributes
Price
© 2009
2017 Global
An organization might Feasibility

study
decide to buy (select) a
product instead of
Requirements
building it.
System System
design selection
Decision typically comes
down to: System System
development configuration
Time
Cost Implement
system
Availability of a
predesigned substitute Post
implementation
review
© 2009
2017 Global
3. Design 3-33
Software requirements:
Informational model
Functional model
Behavioral model
Access control mechanisms

Rights and permissions
Encryption method and algorithms
WBS (Work Breakdown Structure)
Environment where it will be implemented
© 2009
2017 Global
3. Design (Design Specifications) 3-34
Functional model
Data design
Behavioral model
Design = Procedural design
Architectural design
Informational model
01011101 01011101 Program

01000111 01000111
Code
01011101
01111101
01011101
01111101 modules
01011001 01011001
01011101 01011101
01000101 01000101
01011101 01011101
01011000 01011000
01011101 01011101
01011111 01011111
Validate
Test
software
© 2009
2017 Global
4. Development (1) 3-35
Programming language chosen
Programmers become deeply involved
Checking input lengths and other vulnerabilities
Debugging and code reviews
Hooks removed: SW Components intercepting

function calls or messages or events
Separation of duties
Testing
© 2009
2017 Global
Programmers should strive to develop modules
that have high cohesion and low coupling.
Cohesion:
Modules perform a single task with little or no help
from other modules.
Modules have one function with little interaction from
other modules.
The more a module can do on its own, the better.
Requiring a lot of interaction between modules makes
it harder to make modifications without affecting other
modules.
© 2009
2017 Global
Coupling:
Measurement of interconnection between
modules
Lower coupling promotes module
independence (better)
Modular code should:

Be self contained
Perform a single logical function
© 2009
2017 Global
4. Development: Roles and
Responsibilities 3-38
Different roles should be properly

separated so their duties do not
overlap:
Development
Testing
Production
© 2009
2017 Global
5. Installation/ Implementation 3-39
Final user acceptance testing
User guides finalized
Operational and maintenance manuals
Certification
Accreditation
Placed into production

© 2009
2017 Global
5. Installation/ Implementation (cont.) 3-40
Changeover techniques include:
Parallel operation: Old and new systems running at
the same time:
Results between the two systems can be compared.
Fine-tuning new system as needed. As confidence in
the new system improves, shut down the old system.
Primary disadvantage is that both systems must be
maintained for a period of time.
Phased changeover: Systems are upgraded one
piece at a time. Used if system is large.
Hard changeover: All users are forced to change
over at an established date.
© 2009
2017 Global
6. Post-Implementation 3-41
Assess overall success of the project
Determine actual costs vs. projected costs

See how well cost-estimating was done during
feasibility phase
Calculate ROI (return on investment) and

payback analysis
Perform a gap analysis
© 2009
2017 Global
Disposal 3-42
Information may need to be:
Archived/ backed-up
Discarded
Overwritten
Physically destroyed
Media Wipe Standard Description

Rewriteable magnetic
DOD 5220.22-M 3 pass drive
media (CDs/DVDs, Three-pass wiping
wipe or the use of electric
tape, hard drive, flash or degaussing
degaussing
drives, etc.)
Optical media (CD-RW, Physical destruction of the
Physical
DVD-RW, DVD+RW, media by shredding or
destruction
CD-R, DVD-R, etc.) breaking
© 2009
2017 Global
What is DoD 5220.22-M? 3-43
Software based data sanitization method used in

various file shredder and data destruction
programs to overwrite existing information on a
hard drive or other storage device.
Prevent all software based file recovery methods
from lifting information from the drive and should
also prevent most if not all hardware based
recovery methods.
Implemented in the following way:
Pass 1: Writes a ZERO and verifies the write
Pass 2: Writes a ONE and verifies the write
Pass 3: Writes a random character and verifies the write
© 2009
2017 Global
Change Control 3-44
Configuration management
Controlling the lifecycle
Changes must be:

Authorized
Tested
Recorded
Production code must come from the data

librarian, not a programmer
© 2009
2017 Global
Change Control Process 3-45
Although the types of changes vary, change

control follows a predictable process:
1. Request the change
2. Approve the change request
RADTPID
3. Document the change request
4. Test the proposed change
5. Present the results to the change-control
board
6. Implement the change, if approved
7. Document the new configuration
© 2009
2017 Global
Change Control Issues 3-46
Auditor should watch for the possibility of
unauthorized changes because of poor oversight or
the lack of proper security controls such as:
Changes implemented directly by the software vendor,
without internal control
Programmers placing code in an application that has
not been tested or validated
Changed source code that has not been reviewed by
the proper employee
No formal change process is in place
Change not authorized by review board
Programmer access to both the object code and
production library
© 2009
2017 Global
Alternative Application: Development
Techniques 3-47
Auditor must be knowledgeable of other

development methods and have a basic
understanding of their operations.
Some popular models include:

Incremental
Spiral
Prototyping
RAD (Rapid Application Development)
© 2009
2017 Global
Incremental Development 3-48
Develop systems in stages so that development

is performed one step at a time.
A minimal working system might be deployed

while subsequent releases build on
functionality or scope.
© 2009
2017 Global
Spiral Development 3-49
Developed based on experience of waterfall model

Based on the concept that software development is
evolutionary
Begin by creating a series of prototypes to develop a
solution
Spirals out, becoming more detailed
Each step passes through
Planning
Requirements
Risks
Development
© 2009
2017 Global
Prototyping 3-50
Reduces the time required to deploy applications

Uses high-level code to turn design requirements
into application screens and reports users can
review
Allows fine-tuning to improve application based on
user feedback
Works well with top-down testing:
Prototyping clarifies user requirements but it can
result in overly optimistic project timelines.
Might not be properly documented when changed
quickly, which is a real concern for the auditor
© 2009
2017 Global
Rapid Application Development 3-51
RAD uses an evolving prototype and requires heavy

user involvement.
Per ISACA, RAD requires well-trained development
teams that use integrated power tools for modeling
and prototyping.
Strict limits are placed on development time.

RAD has four unique stages:
Concept
Functional design
Development
Deployment
© 2009
2017 Global
Popular Agile Development Models (1) 3-52
XP (Extreme Programming): Requires that

teams include
Business managers
Programmers
End-users
Issues with XP:

Teams are responsible not only for coding, but
also for writing the tests used to verify the code.
XP does not scale well for large projects.
© 2009
2017 Global
Scrum: An iterative development method

Repetitions referred to as sprints, typically
last 30 days
Typically used with object-oriented
technology
Requires strong leadership and a team
meeting each day for a short time
Includes more planning and directing tasks
from project manager to team
Project manager’s main task: Removing obstacles
from the team’s path
© 2009
2017 Global
Reengineering: Converts an existing business

process
Attempts to update software by reusing as

many of the components as possible instead
of designing an entirely new system
© 2009
2017 Global
Application-Development Approaches 3-55
Name Attribute Description
Uses a process of DOSD eliminates problems with

DOSD (Data- focusing on porting and conversion because
oriented software the client uses the data in its pre-
system requirements by described format. Stock
development) focusing on data exchanges, airlines, and bus and
and its structure. transit companies use DOSD.
Uses a process of
OOSD OOSD works with classes and
solution
(Object- objects, and is used in computer-
specifications
oriented aided manufacturing and
and models, with
systems computer-aided software
items grouped as
development) engineering.
objects.
© 2009
2017 Global
Application-Development Approaches
(cont.) 3-56
Name Attribute Description
The benefit of CBD is that it

CBD Uses a process of
enables developers to buy pre-
(Component- enabling objects
developed tested software from
based to communicate
vendors that are ready to be used
development) with each other.
or integrated into an application.
Uses a process to
standardize code WBAD offers standardized
WBAD (Web-
modules to allow integration through the uses of
based
for cross-platform application-development
application
operation and technologies, such as XML
development)
program (Extensible Markup Language).
integration.
© 2009
2017 Global
Summary 3-57
In this domain we:
Described project management

Listed business application
development
Detailed application development
© 2009
2017 Global
Q&A 3-58
QUESTIONS?
© 2009
2017 Global

Section 3: Lifecycle Management: Project Management Business Application Development Application Development

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Section 3: Lifecycle Management: Project Management Business Application Development Application Development

Uploaded by

Copyright:

Available Formats

CISA Examination Preparation Course

Section 3: Lifecycle Management

Business Application Development

After completing this section, you will be

Describe basic project management

List basic business application

Detail application development

To discuss project management, one must

Projects are temporary endeavors (actions).

The purpose of a project is to meet a defined

Projects are unique, in that when all the

Projects have unique

Auditors should be able to identify person(s)

Stakeholders: Have a share or an interest in the

Project steering committee:

Reviews activities of the project team

Formal authority is held by project manager.

Project manager is part of the functional organization

Project manager has some functional authority and

Three constraints of project management:

Time: Can be better established by building a

Cost: Can be determined by examining lines of

Size of the application

Project time constraints

Traditional software sizing has been done

Method was developed because early

Another method is FPA (function point

The five functional point values are:

Number of user inputs

Involves linking individual tasks

Two primary methods:

To schedule activities and monitor progress

Is the preferred tool for estimating time when a

Each PERT chart begins

CPM (critical path methodology) determines what

CPM is accomplished by:

Used when time is the most critical aspect and

Used to lock in specifications and prevent creep

When new software products are released, the

At the conclusion of the project, the project

Project closing tasks include:

Must be able to review information at each step of

Is responsible for reporting independently to

Project feasibility includes:

Cost of the project

Potential benefits to system users

Security controls and checkpoints

Basic components of an ERD

A relationship Entity with

An organization might Feasibility

Access control mechanisms

01011101 01011101 Program

Programmers become deeply involved

Checking input lengths and other vulnerabilities

Debugging and code reviews

Hooks removed: SW Components intercepting

Modular code should:

Different roles should be properly

Final user acceptance testing

User guides finalized

Operational and maintenance manuals

Placed into production

Assess overall success of the project