SAD Short Note System builders

Are technical specialists involved with

(S1)
Information system • Constructing
• An arrangement of Computer and • Testing
Telecommunication Technology to • Delivering the system into operation
support and improve day to day operations
Systems Designer
Main components of an Information System • specializes in creating systems in
• Input (collects data) adherence to the client or company's needs.
• Processing (process data)
• Output (disseminates data) They design the system including
• Feedback • Databases
• Inputs
Computer Based Information Systems(CBIS) • Outputs
• hardware • Screens
• software • Network
• databases • Software to meet the users requirements
• telecommunications
• people System analysts
• procedures • are people who understand
both business and computing
System Development Environment
Stakeholders Role of system analyst
• Any person who has an interest in an • Identify the problem
information system and its outputs. • Analyze and understand the problem
• Identify the solution requirements
Mainly five types
• Identify alternative solutions
• Systems User • Design and implement the best solution
• Systems Owner • Evaluate the result
• Systems Analyst • defining user requirements.
• Systems Designer • gather the necessary data
• Systems Builder • develop models for new systems.
The System analyst’s skills
Systems User
Interpersonal skill:
A “customer” who will use an information system by, • This skills deal with relationships and the interface
• capturing of the analyst with people in business.
Communication:
• validating
• entering • Communication is not just reports, telephone
conversations, and interviews.
• responding to Understanding:
• storing • Identifying problems and assessing their effects
• exchanging Teaching:
• Educating people in use of computer system
Systems Owner Selling:
Person or organization having responsibility for the • Selling ideas and promoting innovations in problem
• Developing solving using computers.
• Operating
• Maintaining the information system. Page1
2
Technical skills: System Objectives
• Focus on procedures and techniques for operations
analysis, systems analysis ,and computer science. Type of information System
Creativity
• Helping users model ideas into concrete plans Transaction Processing System (TPS)
Problem solving
• Reducing problems to their basic levels for analysis
Knowledge computer & the business functions

Technical Skills cont.. Management Information System (MIS)

• Project management: • MIS is an application that provides
Scheduling, performing well management-oriented reporting.
• Dynamic interface:
Blending technical and nontechnical considerations Decision Support System (DSS)
• Questioning attitude and inquiring mind: • Provides decision-oriented information to the user.
Knowing how a system works. • Interactive computer-based modeling process
Analyst’s Personal Attributes
• Authority: Executive Information System (EIS)
The confidence to “tell” people what to do • indicate issues of importance to the organization
• Communication skills: • They integrate data from all over the organization
Ability to focus on a problem area for logical solution. ( into graphical indicators and controls)
• Creativity:
Trying one’s own ideas for developing Expert Systems (ES)
• Responsibility: • Simulates the “thinking “ of the expert.
Making decisions on one’s own • programmed decision making information system
• Varied skills:
• indicate new directions the company may take
Doing different projects and handling change.
analyst’s personal skills
Communications and Collaboration Systems
• Choosing a team to conduct a project
Effective communications between,
• Leading a team
• Workers
• Giving technical ideas
• Partners
• Obtaining information
• Customers
Types of Information Systems
• Suppliers

Classification by Office Automation System

It supports the wide range of business office activities.
mode of processing • Work group computing
• Work group scheduling
Batch processing systems: • E-mail
Transactions are collected as they occur
• Electronic document
On-line batch systems:
• Transaction information is captured by on-line
On-line Real-time systems
• Capturing transaction data as well as
updating & generating reports
4
3
Geographic Information System (GIS) (S2) Systems Development Life Cycle (SDLC)

A system designed to
• capture,
• store,
• manipulate,
• analyze,
• manage,
• present (all types of spatial or geographical data)

information systems by management level.

It is a logical process by build information systems.

Consists of several phases used to
• plan,
• execute
• control
the system development projects.

Legacy Systems We need a life cycle in systems development to,

• potentially problematic • ease the process
• often run on obsolete hardware • build high quality
• hard to maintain, improve and expand • work effectively and efficiently
• avoid failures
Upgrading a Legacy System • maintain and enhance cost effectively
• Force to change
• Many complex legacy systems are yet to
• be upgraded to new technologies because of
• Cost
• Skills
• People required

•
• Main phases of SDLC:
• Systems Investigation(Problem Definition)
• Systems Analysis
• Systems Design
• Systems Implementation
• Systems Testing
• Systems Maintenance pg6
1.Systems Investigation(Problem Definition) 4. System Implementation
This phase identifies and defines a need for the new system. systems implementation phase,
Called project's Terms of Reference (TOR). • individual system components
• user interfaces
• a database
• data and tools

5. System Testing
• Individual program modules are tested by their
developers.
• Integration testing is performed to check whether
the modules can be integrated.
• Designing test cases that test all conditions of the
system input.

6. Maintenance

2. Requirement Analysis (System Analysis) In this phase, the following problems are corrected.
• Fix any bugs and problems found by users
business requirements, expectations, and priorities for a • Eliminate errors in the system during its lifetime.
solution to the business problem • Tune the system into any variation in its working
phase produces environment.
• detailed analysis model • Information system planners must always plan for
• requirements model resource
• system requirements • availability to carry out these maintenance
functions.

(S3)
Major Components of Systems Development
• Methodology
• Modeling Methods or Techniques
• Tools

Methodology
• A very formal and accurate system development
process that defines a set of
• Activities
• Methods
• Best practices
• Deliverables
3. Systems Design • Automated tools
Produces a design specification for the new system.
• Provides the framework
Things done during the design phase: • Has a predefined set of steps
• Identify suitable hardware Eg:
• Specify new programs or changes to existing • SSADM (structured methodologies)
programs • YSM (Yourdon Systems Method)
• Specify new database or changes to existing • STRADIS (Structured Analysis, Design, and
database pg7 Implementation of Information Systems) page 8
Modeling method
• A set of techniques used to implement a
Methodology.
Data Flow Diagrams
• A process model
• The flow of data through a system and the
work performed are represented.
Entity Relationship Diagrams
• A data model
• Depict data in terms of entities and
relationships described by the data
• Consists of several notations
Structure Charts etc.
Waterfall Strengths
Tools
• Easy to understand, easy to use
• Tools are Software systems
• Provides structure to inexperienced staff
• it assists analysts and designers to build information
• Milestones are well understood
systems.
• Sets requirements stability
General Aim :
There are several problems with Waterfall approach.
• Increase the quality of software
• It has a rigid design
• Tools will support methodologies
• Inflexible
• Decrease the human effort to develop the software
• It has a top-down procedure
e.g. Easy Case, Rational Rose • No phase can be repeated
• Time consuming
A software process Modified Waterfall Development Approach
• Uses the same phases
• is the set of activities and associated outcomes that
produce a software product. • Allow some of the stages to overlap
• Progress is more difficult to track.
Software process models When to use the Waterfall Model
• Waterfall model • Attractive for large problems
• Projects which have clear and stable requirements.
• Prototyping models
Prototyping
• Evolutionary models
• A prototype can be used to clear the vague
• The spiral model
requirements.
• Formal development • should be evaluated with user participation.
• Incremental development two types of Prototyping techniques
• Rapid Application Development • Throw-away Prototyping
• Unified Process • Evolutionary Prototyping
• Agile Process Pg10
• Extreme Programming (XP)

Page9
 Prototyping Weaknesses
• Prototyping can lead to false expectations.
• Prototyping can lead to poorly designed systems.
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)
The RAD model
• (RAD) is an incremental software development
process model that emphasizes an extremely short
development cycle.

Throw-away Prototyping
• A throw-away prototype is a cheap, fast prototype that
is designed to model an idea or feature
Problems with Throw-away Prototyping
• Developers may be pressurised by the users to deliver
it as a final system! Processes in the RAD model
• All the man-hours of putting together the throw-away • Business modelling
prototypes are lost, unlike the evolutionary approach. • Data Modelling
• Process Modelling
• Application generation
• Testing and turnover

Evolutionary Prototyping Strengths

• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
Evolutionary Prototyping Disadvantages
• Can be costly to use. Problems with the RAD model
• Management complexity is more. • Requires highly skilled developers/designers.
• Not suitable for smaller projects. • High dependency on modeling skills
• Highly skilled resources are required for risk • The only system that can be modularized can be
analysis. built using RAD.
Pg11 Depends on strong team and individual performances for
identifying business requirements. Pg12
RAD lifecycle
• User requirements are refined.
• A system is designed.
• A prototype is developed.
• The prototype is reviewed by end-user.
• User provide feedback.
• The process is repeated.
Advantages of RAD
• Can speed up systems development.
• Users thoroughly involved from the start.
• Improves the process of rewriting legacy
applications.
• Completes the entire IS in successive iterations.
• Each iteration does some
analysis
design
construction
• Allows versions of usable information to be
delivered in regular and shorter time frames.
• The iteration process helps to develop a part of the
Agile methodology new system
Spiral model
• quadrant 1
• alternatives and constraints.
• quadrant 2
• analyzed form the viewpoint of risk
• quadrant 3
• where the traditional waterfall
model phases are put into practice.
• Quadrant4
• the results of the risk-reduction
strategies

Incremental Development
• Plans and documentation must be produced
• The most important part of the system is first
delivered
• more manageable than evolutionary prototyping
• model involves developing the system in an
incremental fashion.

13

14
Spiral Quadrant
Determine
• Objectives: functionality, performance,
• Alternatives: build, reuse, buy
• Constraints: cost, schedule, interface
• Resolve risks (evaluate if money)
• Study alternatives (relative to objectives and
constraints)
• Identify risks (lack of experience, new
technology)
V-Shaped Strengths
Develop next-level product • Each deliverable must be testable
• Typical activates: • Easy to use
• Create a design • Project management can track progress by
• Review design milestones
• Develop code • Emphasize planning for verification and
• Inspect code validation
• Test product V-Shaped Weaknesses
• Does not easily handle concurrent events
Plan next phase • Does not handle iterations or phases
• Typical activities
• Does not contain risk analysis activities
• Develop project plan
• Does not easily handle dynamic changes
• Develop configuration management plan
• Develop a test plan
• Develop an installation plan
Spiral Model Strengths
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
Spiral Model Weaknesses
• The model is complex
• Risk assessment expertise is required
• hard to define objective Agile methodology
• spent for evaluating risks • is a way to manage a project by breaking it up into
When to use Spiral Model several phases.
• Users are unsure of their needs • Phases: planning, requirements analysis, design,
• Requirements are complex coding, testing, & documentation
• New product line Agile Vs. Iterative
• For medium to high-risk projects • Time period is measured in weeks rather than months
• Work is performed in a highly collaborative manner
• Treating time period as a strict timebox
Agile Vs. Waterfall
• Produce completely developed and tested features
within a phase
• Emphasis is on obtaining the smallest workable piece
of functionality
• Continually improving/adding further functionality
16
15
(S6) Problem Identification Methods Research and site visits
Problem Definition
• Identifying Requirements
first, clearly define what the system must do.
Requirements may be functional or non-functional
Requirements Elicitation
• process of seeking, uncovering, acquiring, and
elaborating requirements for computer-based systems.

Observations of the work environment

• System Analyst participates in or watches a person
perform activities to learn about the system.
• Advantages
• Highly reliable.
• Relatively inexpensive
• Disadvantages
• People usually feel uncomfortable when being
watched

Questionnaires
A questionnaire is a research tool featuring a series of questions
used to collect useful information from respondents.
• Advantages
• Most questionnaires Can be answered quickly.
• Allow individuals to maintain anonymity.
• Relatively inexpensive way of gathering data.
• Responses can be tabulated and analyzed
quickly etc.
• Disadvantages
Requirement Discovery Methods • Number of responses is often low.
(Fact Finding Techniques) • Difficult to prepare
• It is the formal process of using techniques to collect • No guarantee that an individual will answer
information about systems requirements or expand on all the questions
Methods Type of questionnaires
Sampling of existing documents • Free-format:
You can get good idea by studying existing Answer in the space provided after the question.
• Documents • Fixed-format:
• Forms required specific responses from individuals.
• files 1)Yes /No Questions
2) Multiple choice questions
17 3) Rating questions

18
Interviews Operational Feasibility
• System Analyst collects information from individuals • It is a measure of how well a solution meets the
face to face. identified system requirements to solve the problem.
• Advantages Cultural (or Political) Feasibility
• New ideas may arise • deals with how the end users feel about the proposed
• Ability to find the right candidate system.
• Enables detailed assessment Technical Feasibility
• Great source of information • It is a measure of the practicality of a technical solution
• Increase knowledge • availability of technical recourses and expertise
• Disadvantages • three major issues:
• Highly time-consuming • Is the proposed technology or solution
• Risk of personal bias practical?
• Quick to judge
• Do we currently possess the necessary
• Can easily form stereotypes
technology (Hardware/Personnel) ?
• Types of Interviews • Do we possess the necessary technical
• Unstructured interviews expertise?
• Structured interviews Schedule Feasibility
• Types of interview questions • A measure of how reasonable a project time table is.
• Open ended Economic Feasibility
• Closed ended • It is a measure of the cost-effectiveness of a project.
How to conduct an interview? Cost-benefit analysis
• Select interviewees • is always included both tangible and intangible items.
• Prepare an interview guide • Tangible items are those to which direct values can be
• Use clear and concise language. attached
• Avoid long and complex question • Equipment costs for the new system
• Avoid threatening questions • Personnel cost
• verify before you leave • Material costs
• Don’t include your opinion as part of a • Conversion cost
question. • Other costs(consultant’s cost)
Joint requirements planning • Intangible items, are those whose values cannot be
exactly determined
• Highly structured group meeting are conducted to
Determining whether a project is worthwhile
analyze problems and define requirements.
• Payback method
• JRP is a subset of a more comprehensive joint
• defines the time required to recover the money
application development or JAD technique.
spent on a project.
Brainstorming
• Present value method
• let the stakeholders come up with creative ideas or
new approaches to a problem • determine how much money it is worthwhile
investing
(S7) Feasibility Study Legal Feasibility
• The measure of how beneficial an information system • Study to know if the proposed project conforms to the
will be to an organization. legal and ethical requirements.
• Categories of feasibility tests, • copyright law
• Operational Feasibility • non-disclosure clauses
• Cultural / Political Feasibility • code ownership
• Technical Feasibility • labour laws
• foreign trade, and labour regulations
• Schedule Feasibility
• Economic Feasibility • Financial & Accounting standards 20
• Legal Feasibility
19
Feasibility Analysis of candidate systems
• Candidate System Matrix

• Feasibility Analysis Matrix

• During this Feasibility Study phase

• Identifies candidate system solutions
• Analyses the solution for feasibility
• present the system proposal
• Report and oral presentation

(S9) System Design

(S8)The System Proposal Model
A report/ presentation of a recommended solution • Model is a presentation of reality.
Intended for system owners and users..

22
21
Modelling Methods
• Data Flow Diagrams
• A process model
• Depict the flow of data in system
• Entity Relationship Diagrams
– A data model
– Consists of several notations
• Structure Charts etc.
Process Modeling
• graphical representation of business processes or
Decomposition
workflows.
• Break a relation into multiple relations to bring it into
• Systems Analyst may first draw
an appropriate normal form.
Data Flow Diagram OR
Documents Flow Diagram
Logical and physical data flow design
• Logical DFDs-
that illustrate what occurs without showing how it
occurs are known as logical DFDs.
• Physical DFDs-
DFDs that show how things happen or the physical
components are called physical DFDs

Data Flows
• Data flow model the passage of data in the system
and are represented by lines joining system
components.
• Flows of data in the system can take place:
• Between two processes
• From a data store to a process
• From a process to a data store
• From entities to a process
• From process to a entities

23
24
Context diagram
• A common way to begin is to model, the whole
system by one process.
• defines the scope of the system by identifying the
system boundary
contains:
• one process (which represents the entire system)
• all sources/sinks (external entities)
• data flows linking the process to the sources and
sinks (external entities)
Constructing a Context Diagram
• identify and list sources/sinks (external entities)
• identify and list inputs to and outputs from
sources/sinks (external entities)
• create context diagram

Level-0 Diagram
• show one process for each major processing step or
25 functional requirement
26
Drawing a Level-0 Diagram Quality Guidelines
• list the major data stores • Completeness
• list major business steps • all components included & in project
• draw a segment for each business step dictionary
• assemble into single DFD • Consistency
• re-organize until satisfied • between levels: balancing, leveling
• number processes • Timing considerations
DFD context level diagram • assume system never starts and never stops
• Iterative nature
• revisions are common
• Drawing primitives (lowest level)
• when to stop?
DFD Example: Bus Garage Repairs
• Buses come to a garage for repairs.
• A mechanic and helper perform the repair, record the
reason for the repair and record the total cost of all
DFD level 0 diagram
parts used on a Shop Repair Order.
• Information on labor, parts and repair outcome is
used for billing by the Accounting Department, parts
monitoring by the inventory management computer
system and a performance review by the supervisor.

• External Entities:
• Bus, Mechanic,
• Helper,
• Supervisor,
• Inventory Management System,
• Accounting Department, etc.
• Key process (“the system”): performing repairs and
storing information related to repairs
• Processes:
DFD level 1 diagram • Record Bus ID and reason for repair
• Determine parts needed
• Perform repair
• Calculate parts extended and total cost
• Record labor hours, cost
• Data stores:
• Personnel file
• Repairs file
• Bus master list
• Parts list
• Data flows:
Questions about Lower level diagrams • Repair order
1. How deep? (how many levels?) • Bus record
• if the process has only one input or one • Parts record
output, probably cannot partition further; • Employee timecard
2. How broad? (how many processes on a level?) • Invoices
• 7 ± two is a reasonable
• may temporarily place much of the system on
a single diagram then re-draw into separate 28
levels 27
 Explain the term ‘Degree’
• Number of participating entity types.
Degree of Relationship Type
• Unary Relationship
• A relationship between the instances of a
single entity type
e.g. Person is married to a Person
Employee manages Employees
• Binary Relationship
• A relationship between the instances of two
entity types
e.g. An employee works for a department

• Ternary Relationship
• A simultaneous relationship among the
What is a good data flow diagram? instances of three entity types
• The absence of flowchart structures • Supplier s supplies part p to project j
• protection of data
• Good naming conventions
Differences between flowcharts and data flow diagrams
• DFDs are not program flow chats and should not
include control elements.
• A good DFD should;
• Have no data flows that split up into a Cardinality in DBMS
number of other data flows. • Defines the maximum number of relationship
• Have no crossing lines instances in which an entity can participate.
• Not include flowchart loops of control • The possible cardinality ratios for binary
elements relationship types are
• Not include data flows that act as signals to • 1:1
activate processes • 1:N
ER-DIAGRAM • M:N
Conceptual Design

Entity Types
• Strong (Regular) Entity
• An entity that exists independently of other
entity types
29 • Weak Entity
• An entity types whose existence depends on
some other entity 30
 • Identifying Owner ERD Example 2
• The entity type on which the weak entity
type depends
• e.g. Employee is the Owner of Dependent
• Identifying Relationship
• A relationship between a weak entity type
and its owner

Attributes
• Multi-valued Attribute
• An attribute that may take on more than
one value for a given entity instance
• e.g. Employee Skills, Qualifications
• Composite Attribute
• An attribute that can be broken down into
component parts
• e.g. Address (Street, City, State, Postal Code)
• Name (First Name, Middle Initials, Last Name)
Key Attribute (Identifier)
• Identifier
• An attribute (or combination of attributes)
that uniquely identifiers individual instances
of an entity type
• e.g. Emp No
• Composite Identifier
• An identifier that consists of a composite
attribute
• e.g. Flight Id (Flight No, Date)
Associative entities
• are used when you need a relationship to be involved
in a relationship. Method of describing the process
ERD Example 1 • Structured English
Construct an E-R diagram for a hospital with a set of patients • Decision tree
and a set of medical doctors. Associate with each patient a • Decision Table
log of the various tests and examinations conducted. Structured English

Hospital tables:
• Structured English used to
• patients (patient-id, name, insurance, date-
• Explain the conditions which occurs in a
admitted, date-checked-out)
process.
• doctors (doctor-id, name, specialization)
• Identify the decisions which makes these
• test (testid, testname, date, time, result)
conditions occur.
• doctor-patient (patient-id, doctor-id)
• Find alternative actions to be taken
• test-log (testid, patient-id) performed-by (testid,
32
doctor-id) 31
 • The process is defined by using three types of
statements(Developing Structure Statements) (S10)System Design-II
• Sequence structure Data Dictionary
• Decision structure • A document describing a database or collection of
• Iteration structure databases ·
Decision Tree (contains metadata i.e data about the database.)
• A decision tree can help you examine all possible
options when faced with a hard choice or decision.

Synchronization
• Is the process of maintaining consistency between
the different types of models
(S11)System Testing
Types of Tests
• Black-Box Testing
• White-Box Testing
• Gray-Box Testing
Black-box testing
• takes an external perspective of the test object to
derive test cases.
Steps to Create a decision table
• Typical black box test design techniques include:
• List all causes (conditions) in the decision table
• Decision table testing
• Calculate the number of possible combinations
• Pair wise testing
• Fill columns with all possible combinations
• State transition tables
• Reduce test combinations
• Use case testing
• Check covered combinations
• Cross-functional testing
Using Decision Table
White-box testing
• uses an internal perspective of the system to design
test cases based on internal structure.
• Typical white box test design techniques include:
• Control flow testing
• Data flow testing
• Branch testing
Gray Box Testing
• is a software testing method which is a combination
of Black Box Testing method and White Box Testing
System design Approaches method.
• Modern structured design
• Information engineering
• Prototyping
• JAD 34
• RAD
• Object-oriented 33
Levels of testing Integration testing cont..(different types)
• top-down
• to integrated testing where the top integrated modules
• bottom-up
• to integrated testing where the lowest level components
System Testing
• level of the software testing process where a complete,
integrated system/software is tested.
METHOD
• Black Box Testing method is used.
Who performs it
• independent Testers perform System Testing.
User acceptance testing
Unit testing • is the final stage of any software development or change
• unit testing is a software verification and validation request lifecycle before go-live.
method in which a programmer tests if individual Test automation
units of source code are fit for use. • Automated testing tools are sometimes referred to as
Computer Aided Software Testing (CAST) tools.
• performed by using the White Box Testing method
• use of software to
verification and validation
• control the execution of tests
• the comparison of actual outcomes to predicted
outcomes
• the setting up of test preconditions
• test reporting functions.
• two general approaches
• Code-driven testing
• Graphical user interface testing.
Testing Strategy
Benefits of unit testing
• cover the following areas.
• Facilitates change
• Strategy approach-
• allows the programmer to refractor code at a later A testing strategy should be formulated
date • Test plan –
• Simplifies integration A test plan should be developed
• reduce uncertainty in the units themselves • Test design –
• Documentation The logic and reasoning behind the design of the
• provides a sort of living documentation of tests should be explained.
the system • Performing tests –
Limitations of unit testing Detailed procedures should be provided for all
• Software testing is a combinatorial problem tests.
• Testing cannot be expected to catch every error in • Documentation –
It must be clear how the results of tests are to be
the program
documented.
(not catch integration errors or broader system-level • Re-testing –
errors ) The re-test procedure should be explained.
Integration testing The limitations of software testing
• phase in software testing in which individual • Poor testing process
software modules are combined and tested as a • Inadequate time
group. • Future requirements not anticipated
• The purpose verify functional, performance, and • Inadequate test data
reliability requirements placed on major design • Software changes inadequately test
items.
36
METHOD
• Any of Black Box Testing, White Box Testing, and
Gray Box Testing methods can be used. Normally,
the method depends on your definition of ‘unit’.
35
(S12)System Implementation standard package plus additions
Includes • The purchased standard package is not amended itself,
• Source code • but additional software that integrates with the standard
• Database package is developed.
• User documentation • This also may require access to the source code.
• Testing User documentation
• Staff training • Written or visual information about an application system,
• File conversion how it works, and how to use it.
Source code may be in one of the following categories Technical manual
• Standard off- the –shelf package • should include the following;
• Bespoke package – Hardware technical specification
• Amended standard package – System objectives
• standard package plus additions – Flowcharts or Data flow diagrams
Standard off- the –shelf package – Entity models and life histories
• The organization purchases and installs a ready-made – Individual program specifications
solution. – Data dictionary
• Advantages – Contact details for the original developers
• Available immediately – System overview
• Cheaper – System specifications including performance
• High quality details
• Can be update User manual
• Relatively free of bugs • The manual provides full documentation of the operational
• Easy to handle procedures necessary for the ‘hands-on’ running of the
system;
• DisAdvantages • Systems set-up procedures
• It may be not well suited
• Security procedures
• Competitors may well use the same package.
• Reconstruction control procedures
• System messages
The factors to consider when choosing an off-the –shelf
• Samples
application package
Staff training
• User requirements -
• Senior management training
• Processing times
– Executive Support System and Decision Support
• Documentation
System
• Compatibility
– Awareness of information technology, project mgt.
• Controls
skills
• User-interface
• Middle managers training
• Modification
– Computing skill
• cost
– Management information system
• Support maintenance and update
– Office type software
Bespoke package
• Operational staff
• Programmers write an application to meet the specific
– Training should focus on specific tasks
needs of the organization.
File conversion
Advantage
• This may be according to one of four approaches
• The software should meet the organization's specific
1. Direct changeover
needed.
2. Parallel running
• Competitive advantage
3. Pilot operation
• It can make modification for future needs
4. Phased changeover
Disadvantages:
1. Direct changeover
– It make risk
• The old system is completely replaced by the new
– Greater chance of bugs
system in one move
– Waste time and cost
Amended standard package
• This may require access to the source code.(for some
customization)
• Development time should be much quicker.
• User can get good knowledge about the software

37 38
2. Parallel running Kinds of maintenance activities
• The old and new systems are run in parallel for a period • corrective maintenance: correcting errors
of time. • adaptive maintenance: adapting to changes in the
environment (both hardware and software)
• perfective maintenance: adapting to changing user
requirements
• preventive maintenance: increasing the system’s
maintainability

3.pilot operation
• involves selecting parts of an organization to operate
running the new system in parallel with the existing
system.

•
Key to maintenance is in development
• Higher quality  less maintenance (corrective
maintenance)
• Anticipating changes  less maintenance (adaptive and
• perfective maintenance)
4.Phased changeover
• Better tuning to user needs  less maintenance
• Selecting a complete section of the system for a direct
(perfective maintenance)
changeover.Introduce the rest phase by phase.
• Less code  less maintenance
Shift in type of maintenance over time
• Introductory stage: emphasis on user support
• Growth stage: emphasis on correcting faults
• Maturity: emphasis on enhancements
• Decline: emphasis on technology changes
Major causes of maintenance problems
• Unstructured code
•
• Insufficient domain knowledge
• Insufficient documentation

40

•
(S13): System Maintenance
• performing hardware and software installation,
diagnostic and correction and similar activities that are
performed in the usual .

39