Building Systems:

System and Software

Development

Term: 2013/2014
Week 4-5
Management Information Systems
 Systems Development
 The trends of increasing technical complexity of the systems,
coupled with the need for repeatable and predictable process
methodologies, have driven System Developers to establish
system development models or software development life cycle
models.
 Nearly three decades ago the operations in an organization used
to be limited and so it was possible to maintain them using manual
procedures. But with the growing operations of organizations, the
need to automate the various activities increased, since for
manual procedures it was becoming very difficult, slow and
complicated. Like maintaining records for a thousand plus
employees company on papers is definitely a cumbersome job.
So, at that time more and more companies started going for
automation.
 Since there were a lot of organizations, which were opting for
automation, it was felt that some standard and structural
procedure or methodology be introduced in the industry so that the
transition from manual to automated system became easy. The
concept of system life cycle came into existence then.
Systems Development
 System development begins with the recognition
of user needs.
 Then there is a preliminary investigation stage. It
includes evaluation of present system,
information gathering, feasibility study, and
request approval.
 Feasibility study includes technical, economic, legal
and operational feasibility. In economic feasibility
cost-benefit analysis is done.
 After that, there are detailed design,
implementation, testing and maintenance stages.
 Systems Development
 The activities that go into producing an information system
solution to an organizational problem or opportunity are
calles SYSTEMS DEVELOPMENT.
 Systems development is a STRUCTURED PROBLEM
SOLVING with DISTINCT activities like:
 Systems Analysis
 Systems Design
 Programming
 Testing
 Conversion
 Production
 Maintenance
 Software System Development

 Activities here take place in SEQUENTIAL ORDER.

 But, some of these activities may be repeated or take place
simultaneously, depending on the approach to system
building.
 http://msdn.microsoft.com/en-us/beginner/dd547995.aspx
 http://msdn.microsoft.com/en-us/beginner/dd569713.aspx
 http://msdn.microsoft.com/en-us/beginner/dd569717.aspx
System Development Loop
Systems
development

Systems DEFINING THE PROBLEM : Understanding the

current system or need for the system –

Modifications
Revisions

Preventive Actions
Corrective Actions
analysis Requirements List, “Contract”, What is the Gap?

Systems FINDING THE SOLUTION : Designing/Defining the

design “needed/required” system– Specifications, “How it
should be?”

Systems IMPLEMENTING THE SOLUTION :

implementation Building, Project, Hands-on work,
“Closing the Gap”
Documentation
Training PERFORMANCE
Systems
Structural Change EVALUATION : Control,
(+Revision)
Review And Audit Check, “Measuring the
Gap”
Systems
maintenance
and improvement
 Systems Analysis
 The analysis of the problem to be solved with an information
system.
 Defining the problem
 Identifying the causes
 Specifying the solution (several alternative solutions)
 Identifying the information requirements to be met.
 Create a road map of existing organisation and system
 Identify the primary owners and users of data
 Identify the existing hardware and software.
 Detail the problems of existing system
 Examine documents, work papers, procedures
 Observe system operations
 Interview key users of the systems
 Identify the problem areas and objectives of the solution
 Building a new IS
 Improving an existing IS
 Systems Analysis

Identify
solutions

Assess
the Feasibilities
Of each solution

Decide on the
Most feasible
solution
Systems Analysis
 Systems analysis include a FEASIBILITY STUDY
 Is the solution feasible?
 Is the solution achievable?
(Financial, technical, organisational standpoints)
 Feasibility study
 Technical feasibility: Can the development of the proposed system be done with
current equipment, existing software technology, and available personnel? Does it
require new technology? Is the technology needed for the system available? Can the
technology needed be handled by the firms’ IT professionals?
 Economic feasibility: Are there sufficient benefits in creating the system to make
the costs acceptable? An important outcome of the economic feasibility study is the
cost benefit analysis. Is the proposed system a good investment?
 Legal feasibility: It checks if there are any legal hassle in developing the system.
 Operational feasibility: Will the system be used if it is developed and
implemented? Will there be resistance from users that will undermine the possible
application benefits? Can the organisation handle the changes brought by the
system?
 Written systems proposal report describing the costs and benefits, pros and cons of
alternatives. The result of the feasibility study is a formal document, a report detailing the
nature and scope of the proposed solution. It consists of the following:
 Management assessment
 Statement of the problem
 Details of findings
 Findings and recommendations in concise form
Systems Analysis
 all possible alternate solutions : candidate
systems
 weighed and the best alternative of all these is
selected as the solution system, which is termed as
the "proposed system".
 proposed system is evaluated for its feasibility.
 Feasibility for a system means whether it is practical
and beneficial to build that system.
Systems Analysis
Establishing Information Requirements
 Hardest task – what a system should do to meet
information requirements
 Who needs
 What information?
 Where?
 When?
 How?
 Carefully define the objectives of the system
 Develop a detailed description of functions that the system
should perform
 Faulty requirements analysis is a leading cause of systems
failure and high costs
 Either be discarded because of poor performance
 Or undergo major modifications
 Alternative approaches for requirements analysis
What is a Flow chart?
 A flow chart is a graphical or symbolic representation of a process. Each step in
the process is represented by a different symbol and contains a short
description of the process step. The flow chart symbols are linked together with
arrows showing the process flow direction.
 Snap Shot of Business Processes : you can see the process flow at different levels
like a Zoom Lens for Processes.
 Types:

 Names: Process flow chart, process map, process chart, business process model,
process model, process flow diagram, work flow diagram, business flow diagram, or
just flow diagram.
 "Process Map" : flow charts that assign attribute data - inputs and outputs - to each
process step. Also used to refer to flow charts that map the interrelationships between
top level procedures
 Flow Diagram is often synonymous with Data Flow Diagram “ a graphical representation
of the information flow in a computer program”.
 Business Process Modeling (BPM) is usually a sophisticated approach to modeling a
business process used by Business Process Engineers.
What is a Flow chart?
 Categorized in 3 levels: high-mid-low-level (detailed).
 A high-level flow chart could be a process defined at the company-wide or large system
level.
 Mid-level flow chart could be a process defined at the department level
 low-level flow chart could be a process defined at working level.
 Ex: a test department.
 Product validation is a process step included in a high-level flow chart in the “New
Product Introduction procedure”.
 The validation test process itself was documented in a mid-level flow chart showing the
general department activities required to support the validation testing process.
 some ISO work flow instructions had low-level, detailed flow charts documenting how to
conduct individual test types.
What is an Flow chart?
 Terminator: An oval flow chart shape indicating the start or
end of the process.
 Process: A rectangular flow chart shape indicating a normal
process flow step.
 Decision: A diamond flow chart shape indication a branch in
the process flow.
 Connector: A small, labeled, circular flow chart shape used to
indicate a jump in the process flow.
 Data: A parallelogram that indicates data input or output (I/O)
for a process.
 Document: used to indicate a document or report (see image
in sample flow chart below).
Flow Chart –
Process Operation Symbols
Process Show a Process or action step. This is the most common
symbol in both process flowcharts and business process maps.
Predefined A Predefined Process symbol is a marker for another process
Process step or series of process flow steps that are formally defined
(Subroutine) elsewhere. This shape commonly depicts sub-processes (or
subroutines in programming flowcharts). If the sub-process is
considered "known" but not actually defined in a process
procedure, work instruction, or some other process flowchart
or documentation, then it is best not to use this symbol since it
implies a formally defined process.
Alternate As the shape name suggests, this flowchart symbol is used
Process when the process flow step is an alternate to the normal
process step. Flow lines into an alternate process flow step are
typically dashed.
Delay The Delay flowchart symbol depicts any waiting period that is
part of a process. Delay shapes are common in process
mapping.
Preparation As the names states, any process step that is a Preparation
process flow step, such as a set-up operation.
Manual show which process steps are not automated. In data
Operation processing flowcharts, this data flow shape indicates a looping
operation along with a loop limit symbol
 Flow Chart – Control Symbols
Flow Line Flow line connectors show the direction that the process flows.
(Arrow, Connector)
Terminator Terminators show the start and stop points in a process. When used as a Start symbol, terminators
(Terminal Point, Oval) depict a trigger action that sets the process flow into motion.
Decision Indicates a question or branch in the process flow. Typically, a Decision flowchart shape is used when
there are 2 options (Yes/No, No/No-Go, etc.)
Connector Flowchart: In flowcharts, this symbol is typically small and is used as a Connector to show a jump from
(Inspection) one point in the process flow to another. Connectors are usually labeled with capital letters (A, B, AA) to
show matching jump points. They are handy for avoiding flow lines that cross other shapes and flow
lines. They are also handy for jumping to and from a sub-processes defined in a separate area than the
main flowchart.
Process Mapping: In process maps, this symbol is full sized and shows an Inspection point in the
process flow.
Off-Page Connector Off-Page Connector shows continuation of a process flowchart onto another page. When using them in
conjunction with Connectors, it's best to differentiate the labels, e.g. use numbers for Off-Page
Connectors and capital letters for Connectors. In actual practice, most flowcharts just use the Connect
shape for both on-page and off-page references.
Merge merging of multiple processes or information into one. Process Mapping: commonly indicates storage
(Storage) of raw materials.
Extract when a process splits into parallel paths. Also commonly indicates a Measurement, with a capital 'M'
(Measurement) inside the symbol. Process Mapping: commonly indicates storage of finished goods.
Or The logical Or symbol shows when a process diverges - usually for more than 2 branches. When using
this symbol, it is important to label the out-going flow lines to indicate the criteria to follow each
branch.
Summing Junction The logical Summing Junction flowchart shape is shows when multiple branches converge into a single
process. The merge symbol is more common for this use, though. This symbol and the Or symbol are
really more relevant in data processing flow diagrams than in process flowcharts.
Flow Chart –
Input Output Symbols
Data The Data flowchart shape indicates inputs to and
(I/O) outputs from a process. As such, the shape is more
often referred to as an I/O shape than a Data shape.
Document Pretty self explanatory - the Document flowchart
symbol is for a process step that produces a
document.
Multi-Document Same as Document, except, well, multiple
documents. This shape is not as commonly used as
the Document flowchart shape, even when multiple
documents are implied.
Display Indicates a process step where information is
displayed to a person (e.g., PC user, machine
operator).
Manual Input Manual Input flowchart shapes show process steps
where the operator/ user is prompted for information
that must be manually input into a system.
Flow Chart - File and
Information Storage Symbols
Stored Data A general Data Storage flowchart shape used for any
process step that stores data (as opposed to the
more specific shapes to follow next in this table).
Magnetic Disk The most universally recognizable symbol for a data
(Database) storage location, this flowchart shape depicts a
database.
Direct Access Direct Access Storage is a fancy way of saying Hard
Storage Drive.

Internal Storage Used in programming flowcharts to mean

information stored in memory, as opposed to on a
file.
Sequential Although it looks like a 'Q', the symbol is supposed to
Access Storage look
(Magnetic Tape)
Example for System
Development : Training System
 The problem: An organization needs an
“Training Planning and Improvement
System”
 Current system is run manually by HR unit,
using messaging – e-mail system, Word
documents, Excel reports
 Example for System
Development : Training System
 Current System Work Flow: MAIN PROCESS STEPS

Training Planning Training

- Needs Evaluation
Analysis Implementation -Evaluation
-Survey Questionnaire
-Programme design -Analysis
-Organization

Training
Reports
-Programme outputs
-Executive Reports
-Comparative Reports
 Example for System
Development : Training System
 Current System Work Flow: PLANNING
Organize locations, Select trainings
inform HR
Prepare
draft training list
Approve/reject selections
Prepare training list with of employees
Trainer, dates, locations

Approve draft training Send survey results

List, add principles to HR
Approve training plan

Control and send results

Contact potential Send Training Plan to To management
Trainers Supervisors

Approve/reject selections
of employees
Accept trainership* Select employees
Give possible dates for trainings

Send invitations to
Send training plan to
Finalize dates, contact employees and trainers
Employees with
Administration for location
comments
 Example for System
Development : Training System
 Current System Work Flow: IMPLEMENTATION
Prepare training Take signatures from
Documents, Prepare training locations participants
send them to HR
Return signed lists to
HR
Meet trainers, participants
Cover, organize and
copy Documents Take account information
from Outsource
Give participants lists,
trainers
documents to trainer
Prepare attendance
Lists Inform accounting
Give documents to For payment
participants Transfer
Payment to trainer
Follow up and
conclude payment
 Example for System
Development : Training System
 Current System Work Flow: EVALUATION

Prepare Approve reports

Enter questionnaire results Send comments to HR
Questionnaire
To Excel

Corrections if needed
Prepare evaluation results
IMPLEMENTATION
reports
Send results to trainers

Prepare executive report

Analyse and comment
On results of QS
Send reports to management
Analyse results and
Prepare an improvement
Actions report
Example for System
Development : Training
Insufficiencies of current system.

System
 Long time needed for planning
 Continous need for data entry in HR Unit
 Difficulties in tracking and including changes in the personnel
 Multiple data in different environments
 Difficulties and time waste in reporting
 Lack of control on the process
 Difficulties in monitoring the process
 REcords stored on PC’s- Unsystematic archiving
 Lack of collaboration and communication during the process
 High level of human intervention
 Lack of automatic integration with other related systems
 Difficulties in defining the areas of improvement
 Inability to store and manage training documents/lecture notes
systematically
Example for System
Development : Training System
 CHECK OUT FOLLOWİNG ADDITIONAL DOCUMENTS ON
SYSTEM DESIGN OF THE SAMPLE SYSTEM:

 TermProjectSample_ProposedSystemDesign
 TermProjectSample_ProposedSystem_SimpleDataF
low
 ETKINLIKEGITIMMODUL (PDF)
 egitimetkinlikmodul_processchart (JPG,VSD)
Systems Design
 The purpose of the design phase is to plan a
solution of the problem specified by the
requirement document – first step for moving
from problem domain to the solution domain.
 The design of a system is perhaps the most
critical factor affecting the quality of the software,
and has a major impact on the later phases,
particularly testing and maintenance.
 The output of this phase is the design document.
 This document is similar to a blue print or plan for
the solution, and is used later during
implementation, testing and maintenance.
 Systems Design
 Types of specifications to be produced by system design
Systems Design
 Shows how the system will fulfill the objective of systems analysis
 Systems design is the OVERALL PLAN or MODEL FOR THE SYSTEM
 Like Blue print of a building – like houses and buildings IS may have many
possible designs
 Consists of all specifications that give the system its FORM and
STRUCTURE
 Carefully define the objectives of the system
 Detail the system specifications that will deliver the functions identified
during the systems analysis
 Specs should adress all components of the system solution
 Managerial
 Organisational
 Technological
 Each design represents a unique blend of all components- Alternative
approaches for requirements analysis
 Superior design is the “easy and efficient” design that
 fulfills USER REQUIREMENTS
 Within a specific set of CONSTRAINTS (technical, organisational, financial,
time)
Systems Design
 The design activity is often divided into two separate phase-system
design and detailed design. 2 documents are prepared.
 System design, ( top-level design): what components are needed
 identify the modules that should be in the system,
 the specifications of these modules,
 interactions with each other to produce the desired results.
 At the end of system design all the major data structures, file
formats, output formats, as well as the major modules in the
system and their specifications are decided
 Detailed design: how the components can be implemented in
software is the issue
 the internal logic of each of the modules specified in system
design
 further details of the data structures and algorithmic design of each
of the modules is specified.
 The logic of a module is usually specified in a high-level design
description language, which is independent of the target language
in which the software will eventually be implemented.
 Like every other phase, the design phase ends with verification of
the design
Systems Design –
Role of End Users
 User information requirements drive the entire
system-building effort
 Users must have sufficient control over the design
process to ensure the system reflects their
priorities and information needs
 Not the biases of technical staff
 Working on design increases users’
understanding and acceptance of the system
 Insufficient user involvement in the design effort is
a major cause of system failure
 USer participation in alternative system development
methods
Completing the systems development
process

 Remaining steps in systems development process

translate the solution specs established in
systems analysis and design into a fully
operational information system
 Programming
 Testing
 Conversion
 Production
 Maintenance
Systems Programming
 System specs are translated into software
program code. May be ;
 Outsourced
 Purchase of the software package from a vendor
 Purchase of software services from ASP (Application
Service Provider)
 Developed in-house
Systems Programming
 Once the design is complete, most of the major
decisions about the system have been made.
 The goal of the coding phase is to
 translate the design of the system into code in a
given programming language.
 to implement the design in the best possible manner.
 The coding phase affects both testing and
maintenance profoundly. A well written code
reduces the testing and maintenance effort.
 the focus should be on developing programs that
are easy to write. Simplicity and clarity should be
strived for, during the coding phase.
Testing
 Exhaustive and thorough testing to ascertaion
whether the system produces the right results
 Will the system produce the desired results under
known conditions?
 Do not underrate the time needed for testing in
project plan
 Test data must be carefully prepared
 Results must be reviewed
 Corrections must be made
 Maybe a part of the system will be redesigned
Testing Steps
 1. Unit Testing (Program testing)
 Testing each program separately in the system
 to locate errors in the programs
 To focus on finding all the ways to make a program fail
 (Not to quarantee that programs are error free- it is impossible)
 Find the problem, than correct it
 2. Systems Testing
 Testing the functioning to the IS as a whole.
 Try to determine whether the discrete modules function together as
planned
 Try to determine discrepencies that exist between the way system works
and the way it was conceived
 Performance time
 Capacity for file storage
 Handling peak loads
 REcovery and start capabilities
 Manual procedures
 3. Acceptance Testing
 Final certification of the system – ready to be used in production
 Acceptance tests are evaluated by users and reviewed by management- all
parties should be satisfied
 Testing Steps
 Work with users to devise a systematic test plan
 Test plan includes all preperations of all testing types
 When developing a test plan, the various conditions should be tested, the
requirements of each condition tested, and the expected results. Test plans
require input from both end users and IT specialists .

Example of a test plan: Condition being tested is a record change. The documentation consists of a series of
test plan screens maintained on a database (perhaps a PC database) that is ideally suited to this application.
 Testing Plan
1) Indicate the type of the test plans to be included in Testing
 Master Test Plan: A single high-level test plan for a project/product
that unifies all other test plans.
 Testing Level Specific Test Plans: Plans for each level of testing.
 Unit Test Plan
 System Test Plan (including Integrations)
 Acceptance Test Plan
 Testing Type Specific Test Plans: Plans for major types of testing
like Performance Test Plan and Security Test Plan
2) Scope and Features: List the Tested Items (software/products) and
their versions. List the Features to be Tested and not to be tested
 Provide references to the Requirements and/or Design specifications of
the features to be tested
 Specify the reasons these features won’t be tested.
 Testing Plan
3) List the Major Constraints
 Any organizational or technical constraints that impact the testintg (lack
of resources, personnel, incomplete programming etc.)
4) Approach:
 Mention the overall approach to testing.
 Specify the testing methods [Manual/Automated; Black, white, grey
box]
 Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal
structure/design/implementation of the item being tested is not known to the tester. Example: A tester, without
knowledge of the internal structures of a website, tests the web pages by using a browser; providing inputs
(clicks, keystrokes) and verifying the outputs against the expected outcome. The higher the level, and
hence the bigger and more complex the box, the more black box testing method comes into
use.
 White Box Testing is a software testing method in which the internal structure/design/implementation of the
item being tested is known to the tester. The tester chooses inputs to exercise paths through the code and
determines the appropriate outputs. Programming know-how and the implementation knowledge is essential.
White box testing is testing beyond the user interface and into the nitty-gritty of a system. Example: tester,
usually a developer as well, studies the implementation code of a certain field on a webpage, determines all
legal (valid and invalid) AND illegal inputs and verifies the outputs against the expected outcomes, which is
also determined by studying the implementation code. Generally used for unit testing
 Testing Plan
5) Item Pass/Fail Criteria:
 Specify the criteria that will be used to determine whether each test
item (software/product) has passed or failed testing.
6) Schedule:
 When and how often will the tests will be done?
7) Staffing Needs and Responsibilities/approvals
 Specify staffing needs by role and required skills.
 List the responsibilities of each team/role/individual.
7) Staffing Needs and Responsibilities/approvals
 Specify staffing needs by role and required skills.
 List the responsibilities of each team/role/individual.
Testing Plan
Conversion
 Process of changing from the old system to the new system.
 1. Parallel Strategy: Both the old system and its potential
replacement run together for a time until everyone is assured that
the new one functions correctly.
 Safest conversion approach for the event of errors or processing
disruptions, the old system can be used as back up.
 Most expensive , requires resource allocation
 2. Direct Cutover: replaces the old system entirely with the new
system on an appointed day.
 Risky approach,
 May be costly then running two systems if serious problems occur.
Testing the functioning to the IS as a whole.
 3. Pilot Study : introduces the new system to only a limited area,
such as a single department or unit.
 When this version is complete and working smoothly, it is installed
thoroughout the rest of the organisation.
 4. Phased Approach: introduces the new system in stages, either
by functions or by organisational units.
Production and Maintanance
 After the new system is installed and conversion is
complete, the system is said to be in production.
 The system will be reviewed by both users and technical
specialists to
 determine “how well it has met its original objectives”
 to decide “whether any revisions/modifications are
needed”.
 Is a “postimplementation audit” needed?
 After the system is fine tuned, it must be maintained while it
is in production to correct errors, meet requirements,
improve efficiency
 Maintenance: Changes in hardware, software,
documentation, procedures.
 20% percent of maintenance time is used for “debugging”
or “correcting” emergency problems.
 20% percent of maintenance time is concerned with
changes in data, files, reports, hardware, system software
Systems Development
 Software System Development
Structured Methodologies
• Structured refers to the fact that techniques are step
by step, with each step building on the previous one.

• Data flow diagram: Primary tool for structured analysis that

graphically illustrates a system’s component processes and the
flow of data between them.

• Process specifications: Specifications that describe the

logic of the processes occurring within the lowest levels of a data
flow diagram.

• Structure chart: System documentation showing each level

of design, the relationship among the levels, and the overall
place in the design structure; can document one program, one
system, or part of one program.
Software System Development
Structured Methodologies
Software System Development
Structured Methodologies
Software System Development
Sample Project Life Cycle

You will find out

Or you will
create

You already
know or
You can guess
Term
Project
Scope
Software System Development
Sample Intranet Project
Scope of a Software Production
Project