Fundamentals chapter 11 Flashcards
Systems analysis
Participants in Systems development
Systems are developed by a Development Team
Users: People who will interact with the system regularly
Systems analyst: Professional who specializes in analyzing and designing business systems
Programmers: Responsible for modifying or developing programs to satisfy user requirements
Managers:
Vendors and suppliers:
Technical Specialists:
Role of the systems analysts
Plays an important role in the development team and is often the only person who sees the system in its totality
A person who is often called on to be a facilitator, moderator, negotiator and interpreter for development activities
Information Systems Planning for Aligning Organisation and IS Goals
Information systems planning:
Involves translating strategic and organisational goals into systems development initiatives
Strategic goals are finite, measureable and tangible.
Aligning organisational goals and IS goals is critical for successful systems development effort
Process
Strategic plan
IS planning
Systems development initiatives
Steps in information systems planning
- Consult the organizational strategic plan
- Develop overall objectives
- Identify IS projects(Includes previously unplanned systems projects)
- Set priorities and select projects
- Analyze resource requirements
- Set schedules and deadlines
- Develop IS planning document
The overall objective of systems development
is to achieve business goals, NOT technical goals
The success or failure of a systems development effort will be measured against:
PERFORMANCE OBJECTIVES – the extent to which a system performs as desired
COST OBJECTIVES – the extent to which the benefits of achieving performance goals balance or outweigh all the costs associated with the system
Factors that determine system performance
1.The quality or usefulness of the output
a.Generates the right information for a business process; by the right person
2.The accuracy of the output
b.Information must be error-free; reflect the true situation
3.The quality or usefulness of the format of the output
c.Information must be readable (screen and/or paper) and simple
4.The speed at which output is generated
d.Information must be timely
5.The scalability of the resulting system
e.Must allow for future growth
6.The degree to which business risk is reduced
Factors that determine system cost
1.Development costs
Costs to get the system up and running
2.Costs related to the uniqueness of the system application
An expensive but reusable system might be better than a less costly system with limited use
3.Fixed investments in hardware and related equipment
Developers should consider costs of such items as computers, network-related equipment and environmentally controlled data centres in which to operate the equipment
4.Ongoing operating costs
Operating costs include costs for personnel, software, supplies and resources such as the electricity required to run the system.
A new project will be initiated and the cycle will start over if:
- the system needs significant improvement beyond the scope of maintenance, or
2.it needs to be replaced because of a new generation of technology, or
3.the IS needs of the organization change significantly
SDLC types or approaches
1.Traditional Systems Development Lifecycle
2.Prototyping
3.Rapid Application Development
Agile Development
Joint Application Development (JAD)
4.End-User Systems Development Lifecycle
Traditional SDLC steps
Systems investigation
Systems analysis
Systems design
Systems implementation
Systems maintenance and review
Systems investigation
1.Identifies problems and opportunities and considers them in light of business goals
2.Studies existing systems and work processes to identify strengths, weaknesses, and opportunities for improvement
Systems design
Defines how the information system will do what it must do to obtain the problem’s solution
Systems implementation
Creates or acquires various system components detailed in systems design, assembles them, and places new or modified system into operation
Systems maintenance and review
Ensures the system operates as intended
Modifies the system so that it continues to meet changing business needs
Prototyping
Also know as the evolutionary lifecycle
It begins with creating a preliminary model of a major sub-system
Through an iterative analysis and design process the preliminary model is refined and incrementally better versions are created
Operational prototype
- Has functionality(does something towards solving the problem)
- May accept input, process it, and generate output
- In second iteration, processing may be refined and expanded
Non-operational prototype
- Has very limited, if any functionality (mock-up or model)
- Includes input and output specifications, but output is stimulated
- Developed easily
- Can be discarded
Rapid application development
Employs tools, techniques, and methodologies designed to speed application development
Tools used in RAD:
Rational Rapid Developer by Rational Software
OptimalJ by Locus Systems
Advantage Gen by Computer Associates International
Other approaches to RAD
Agile Development
Allow the systems to change as they are being developed
Requires frequent face-to-face meetings with systems developers and users as they
Modify
Refine and
Test how the system meets the users’ requirements
Leads to robust systems with fewer errors when using Extreme Programming (XP) – a rapid iterative process involving pairs of programmers who design, test and code parts of the system
Joint application development
RAD makes use of JAD
Process for data collection and requirements analysis Involves:
Group meetings in which users, stakeholders and IS professionals work together to
Analyse existing systems,
Propose possible solutions, and
Define the requirements for a new or a modified system
Needs a representative from management to be effective
Goes a long way to improving systems requirements
Factors affecting systems development success
Getting users and stakeholders involved
Degree of change
Managing change
Quality and standards
Getting users and stakeholders involved
1.Top management support is needed
2.Establish clear communication between
a. Domain side (users, managers, other stakeholders), and
b. Systems side (systems analysts, programmers, and other technical people)
3.Helps avoid user resistance to changed (new) systems
Degree of change
- Continuous improvement vs reengineering projects
a. Continuous improvement projects have a high degree of success
b. Reengineering projects tend to have a high degree of risk but also a high potential for benefits
Managing change
Users concerns include:
1.Fear of loss of job, power, or influence at work
2.Belief that new system will create more work
3.Don’t want to work with ‘computer people’
4.Fear that the new system will change the organizational structure
5.Not willing to learn new procedures or approaches
Quality and standards
- Quality of project planning
a. Bigger the projects, more likely poor planning will lead to failure
b. Often fall behind schedule ,go over budget, and do not meet the users expectations - Constant trade-off schedule +cost vs quality
a. Often more concern on schedule +cost, than quality
3.International Standards Organization(ISO) provides standards to assist in improving the quality of IS
Critical for most systems development projects cont.
Use of Project Management Tools
a. Project management involves:
1.Planning
2.Scheduling
3.Directing and controlling human
4.Financial and
5.Technological resources for a defined task whose result is achievement of specific goals and objectives
b. Applies to large and small projects
Typical reasons to initiate a systems development project
1.Problem with existing system
2.Desire to exploit new opportunities
3. Increasing competition
4.Desire to make more effective use of information
5.Organizational growth
6.Merger or acquisition
7.Change in the environment
Advantages of the traditional SDLC
1.Formal review at the end of each phase allows maximum management control
2.This approach creates considerable system documentation
3.Formal documentation ensures that system requirements can be traced back to stated business needs
4.It produces many intermediate(partial) products that can be reviewed to see whether they meet the users’ needs and conform to standards
Disadvantages of the traditional SDLC
1.Users get a system that meets the needs as understood by developers; this might not be what they really needed
2.Documentation is expensive and time consuming to create. It is also difficult to keep current
3.Often, user needs go unstated or are misunderstood
4.Users cannot easily review intermediate (partial) products and evaluate whether a particular product meets their business requirements
Advantages of prototyping
1.Users can try the system and provide constructive feedback during development
2.An operational prototype can be produced in weeks
3.As solutions emerge, users become more positive about the process and the results
4.Prototyping enables early detection of errors and omissions
Disadvantages of prototyping
- Each iteration builds on the previous one. The final solution might be only incrementally better than the initial solution.
- Formal end-of-phase reviews might not occur. Thus, it is very difficult to contain the scope of the prototype, and the project never seems to end.
3.Systems documentation is often absent or incomplete because the primary focus is on the development of the prototype
4.System backup and recovery, performance ,and security issues can be overlooked in the haste to develop a prototype
Advantages of rad
1.Puts an application into production sooner than any other approach
2.Documentation is produced as a by-product of completing project tasks
3.RAD forces teamwork and lots of interaction between users and stakeholders
Disadvantages of rad
1.This intense SDLC can burn out systems developers and other project participants
2.This approach requires analysts and users to be skilled in RAD system development tools and RAD techniques
3.RAD requires a larger percentage of stakeholders’ and users’ time than other approaches
Planning issues that frequently contribute to project failure
read slides
