Information systems development Flashcards
1
Q
What is IS development?
A
- Refers to the process of planning, creating, testing, and deploying an information system
- idea → analysis → design and implementation → completed information system
2
Q
Reasons for Project Initiation
A
- current system cannot cope
- cost savings
- provision of better internal information for decision making
- provision of better customer service
- opportunities provided by new technology
- high-technology image
- change in legislation
- balancing the portfolio of projects
3
Q
Build software
A
- customised
- developed in-house
- developed by outside vendor
- full control can be beneficial if software is strategically important
4
Q
Buy software
A
- prepackaged software
- select software vendor
- customisation may be offered by software vendor for a price
5
Q
Costs to consider when making
A
- Initial cost of building a system
- Cost of enhancing the system with new features
- Cost of repairing defects and bugs
- Cost of customer support
- Cost of refactoring
- Removal of error-prone modules
6
Q
Costs to consider when buying
A
- Cost to purchase software
- Cost to customize software
- Licenses for named or concurrent users
- Cost of infrastructure that software will run on: servers, network connections, network upgrades to support higher loads or number of transactions
- Staffing: training, maintenance, support, administration, incidental personnel
7
Q
When does “Making” make sense?
A
- Making software may be associated with risks
- Carefully considering potential costs is essential
- Strategic software is custom software
- In-house development is even more critical if you wish to retain your firm’s advantage
8
Q
factors of making
A
+ higher customisability (important for e.g. displaying code properly)
+ possibility of re-sell
+ higher chance of familiarity with product
+ easier to integrate with rest of internal systems
+ full control and strategic advantage
+ no dependency on external vendors
+ can be interconnected to other systems
- security concerns
- high risks for defining requirements and the cost
- the need for full-support and maintenance
- the need to keep up-to-date technology
9
Q
factors of buying
A
+ easier to maintain
+ faster to get to the actual usage
+ scalability, better performance?
+ product can be tried
+ possible to choose among vendors
+ customisation can be possible
+ possible to extend/connect to existing systems
- dependency on another business
- cost is clear, but many require high initial investment
- responsibilities can be transferred to the vendor
- license limitations
10
Q
Systems Development Process
A
- initiation → start up phase
- analysis → define requirements
- design → specify system configuration
- development → programming and configuring the system
- installing and testing the system
- monitoring and revising the system
11
Q
the waterfall model
A
- initiation
- analysis
- design
- development
- implementation
- maintenance
- changes to requirements or errors in the system require each stage to be revised
- project proceeds to the next stage once the current stage is complete
12
Q
Prototyping
A
- Prototyping is a common approach to developing information systems which is used to counter the problems of the waterfall model
- The essence of prototyping is that it is:
- Rapid
- Simple
- Iterative
- Incremental
- User-centred
- Once the first prototype has been produced there are several alternatives:
- Iterate and produce further refinements, which often occurs throughout the specification stage
- Develop module prototypes
- Throw away the prototype and develop a more robust version of the software for the production version
- Repeated iterations of the analysis, design, develop, test and review stages occur during prototyping
- So, the approach to prototyping should be considered
carefully
13
Q
three different types of prototyping
A
- Throwaway or low-fidelity prototyping
- Evolutionary prototyping or high-fidelity prototyping
14
Q
System analysis
A
- Goal is to build a logical model of the system
- Question: What must be done in order to satisfy the objectives and functions of the system under investigation?
15
Q
2 main parts of systems anakysis
A
- Data analysis: Which data has to be stored
- Process analysis: Aims at showing the activity flow of the system, e.g. interactions with the system
16
Q
Participants in Analysis and Design
A
- business side: user/domain expert/ client
- mediator: business analyst
- IT side: developer/programmer
17
Q
challenges in systems analysis
A
Challenge 1: Fragmented process knowledge
Challenge 2: Domain experts think on instance level
Challenge 3: knowledge about process modelling is rare
18
Q
Key aspects of System analysis
A
- Focus Groups
- Documentation
- Surveys
- Observation
- Interviews
- Prototyping
- Producing the requirements specification
19
Q
Focus Groups
A
- Focus groups or brainstorming are useful at an initial stage
- Helps to identify major organizational and process
- Helps in identifying the issues which the project should address, and these can then be followed up in more detail with the other requirements-gathering techniques
20
Q
Documentation
A
- A range of documentation may be available from existing systems
- This may include
- previous requirements specifications
- user guides
- procedure manuals or
- help systems
- Pre-existing good-quality documentation may make
documenting the requirements of the new easier
21
Q
Surveys
A
- Questionnaires are sent to potential users of the system and users of the existing system
- These also provide a structured method of requirements gathering
- It is possible to determine key features by asking respondents closed questions such as selecting from a list or asking more general open questions such as ‘What are the three best and worst features of the current system?’
- Surveys work best if performed before interviews
22
Q
Observation
A
- Assessing how users of the current system work when completing different activities
- It is an essential technique for identifying inefficiencies in a
system - It is less clear at which point observation should occur in the sequence of requirements determination activities
- It will often occur in parallel with other activities
23
Q
Interviews
A
- Interviews are a more structured form of collecting requirements than focus groups
- They give an individual time to reflect on their needs and describe problems with the existing system
- Detailed requirements are collected so it makes sense if these happen towards the end of requirements gathering
- Some interviews with managers may be useful at an earlier stage in requirements determination
- Interviews work best if they are semi-structured, with a prepared script of questions which must be answered but flexibility for other concerns to be described
24
Q
Prototyping
A
Prototyping of new systems through paper or on-screen prototypes will in itself elicit requirements
25
Q
Producing the requirements specification
A
- The requirements specification will detail how the system should support its users and business processes
- It will include:
- Business requirements – what are the required business outcomes of developing the new system?
- Summary of system users and their general requirements
- Process support requirements – which work activities will the system support?
- Data output requirements – what information will be available to users and managers of the system?
- Data input requirements – what information will be captured for the system, what will its source be (other systems and manual data entry)?
- Data visualization requirements – how will data be entered and viewed by users?
