Download
1 / 67
670 likes | 818 Views
Chapter 5 – Chapter 9. People Themes Modelling Themes Rapid and Evolutionary Development Engineering Themes External Development. Learning Objectives. Describe the role of people in developing and using information systems.
E N D
Chapter 5 – Chapter 9 PeopleThemes Modelling Themes Rapid and Evolutionary Development Engineering Themes External Development
Learning Objectives • Describe the role of people in developing and using information systems. • Explain modelling and approaches that emphasize the modelling aspects (data / process). • Discuss the speedy delivery of applications. • Describe software engineering. • Discuss the alternative approach for procurement of information system.
Why is there a need for people to beinvolved in ISD? • Importance of user involvement/participation in systems development: • user/developer communication and cultures • The developer as “technical expert” • Lack of user satisfaction and commitment • Technical success is not enough – need to ensure it meets the client’s needs • User vs IT department relations
DeLone and Mclean (2003) synthesized a six factor taxonomy of IS success from the diversity of IS success measures used in the literature. Output produced by a system and the value, usefulness or relative importance attributed to it by the user IS impact measures, such as individual user impacts, work group impacts , inter-organizational and industry impacts, consumer impacts, and societal impacts. Consumption of IS output How well the system is able to serve the needs of the users Visibility Simplicity Consistency Flexibility Providing support for end user developers User response to the output characteristics of an IS Source :http://mtsu32.mtsu.edu:11409/698-Delone&McLean-TenYearUpdate.pdf
Different angles of user involvement inISD 1. User participation 2. End user computing 3. Stakeholder analysis 4. JAD (Joint Application Development) Early systems development approaches: - focus on technical aspects of computer systems - little actual decision-making by users Problems: - users resented developers as “outsiders” with little understanding of the business environment - systems “imposed” on users and not “user friendly” - systems did not adequately support business needs
User reactions • Users may regard the IT department as having too much power and control over other departments through the use of technology • Users may regard computer people as having too great a status in the organisation, and they may not seem to be governed by the same conditions of work as the rest of the organisation • Users may consider the pay scales of computer staff to be higher than their own and that the poor track record of computer applications should have led to reduced salaries and status, not the opposite
Three levels of participation(Mumford 1983b) Three levels are identified by Mumford (1983): • Consultative participation • all users are consulted about /c ontribute ideas to the design process but the design task is carried out by systems analysts • Representative participation • design groups formed from elected or selected representatives, who take design decisions • Consensus participation • design group members constantly discuss ideas and solutions with • all users
User participation :Expectedbenefits of user participation • Improved system quality: • more complete, accurate requirements • provides expertise about the organisation • avoids development of unacceptable or unimportant • features • improves user understanding of the system • Increased user acceptance: • realistic expectations • “arena” for conflict resolution • users more committed to the system • decreased user resistance
User participation and ISD methodologies • Structured analysis • user walkthroughs, users select implementation option • SSADM • user walkthroughs, user representation in development teams, • users select technical option • Information Engineering • users active in design activities, management involved in ISP and • BAA, user reviews • SSM (soft systems methodology) • users part of team: problem owners and solvers
Users SYSTEM DESIGNERS express requirements to system designers interpret requirements and try to meet them through a computer system USERS express information as data USERS interpret data as information COMPUTER DATA DATA
End user computing • Definition of end-user computing: “the practice of end-users developing, maintaining,and using their own information systems” (Mirani and King 1994) • Enabled by PCs and application packages for non-IT People (e.g. spreadsheets, database, VisualBASIC etc) • Users in business organisations are able to build their own business applications, either stand-alone or integrated with organisational systems • Allows for decentralisation of computing resources
Non-programming end-users Command-level users End-user programmers Functional support personnel Information Centers Defining the domains of responsibility Provision of an EUC infrastructure Provision of software and tools Support of EUC users Setting of standards for EUC Co-ordination and control of EUC in the organisation Procurement Dealing with external partners End user computing
Expert system An expert system is regarded as the embodiment within a computer of a knowledge-based component from an expert skill in such a form that the system can offer intelligent advice or take an intelligent decision about a processing function. A desirable additional characteristic, which many would consider fundamental, is the capability of the system, on demand, to justify its own line of reasoning in a manner directly intelligible to the enquirer. The style adopted to attain these characteristics is rule-based programming.
Structure of an expert system • Components of ES • Knowledgebase • Frames • Inference engine • Language • Shell • Explanation generator • Blackboard • User interface • Environment
Knowledge management Knowledge is a fluid mix of framed experience, values, contextual information, expert insight and grounded intuition that provides an environment and framework for evaluating and incorporating new experiences and information. It originates and is applied in the minds of knowers. In organizations, it often becomes embedded not only in documents or repositories but also in organizational routines, processes, practices, and norms.
Key drivers for knowledge management (Tiwana 2000) • Knowledge-centric drivers: • The failure of companies to know what they already know • The emergent need for smart knowledge distribution • Knowledge velocity and sluggishness • The problem of knowledge walkouts and high dependence on tacit knowledge • The need to deal with knowledge-hoarding propensity among employees • A need for systemic unlearning.
Key drivers for knowledge management (Tiwana 2000) • Technology drivers: • The death of technology as a viable long-term differentiator • Compression of product and process life cycles • The need for a perfect link between knowledge, business strategy, and information technology
Key drivers for knowledge management (Tiwana 2000) • Economic drivers: • The potential for creating extraordinary leverage through knowledge; the attractive economics of increasing returns • The quest for a silver bullet for product and service differentiation
Key drivers for knowledge management (Tiwana 2000) • Personnel drivers: • Widespread functional convergence • The need to support effective cross-functional collaboration • Team mobility and fluidity • The need to deal with complex corporate expectations
Key drivers for knowledge management (Tiwana 2000) • Process focused drivers: • The need to avoid repeated and often-expensive mistakes • Need to avoid unnecessary reinvention • The need for accurate predictive anticipation • The emerging need for competitive responsiveness
Customer orientation • Customer Relationship Management (CRM) is concerned with using IT to attract customers to the organization and keeping them loyal to the company. ‘Delivering value to customers will bring value to the organizations’
Requirements • everything that the set of relevant stakeholders (users, end-users, line management, senior management, customers and regulators) want from a system. • Requirements – is a description of what a system should do. It is useful to distinguish between the world in which the problem exists (the ‘application domain’) and the world in which software solutions are developed (the ‘machine domain’). These worlds overlap in a limited way, and it is this overlap that allows us to take the application domain requirements that we care about and translate them into relationships between inputs and outputs that the software can control.
Functional vs. Non-functional Requirements • Functional requirements capture the functions that a system must perform, while non-functional requirements capture general properties about the system, such as its speed, usability, safety, reliability, and so on. • Nonfunctional requirements are often also called ‘system qualities’, or ‘ilities’.
Model An analysts will create diagrammatic models of a target or proposed system in order to: • understand the system, and • communicate: • to demonstrate, or clarify, understanding of the existing system and/or to obtain feedback from users/clients; • to describe unambiguously the proposed computer system to users/clients and to the programming team. A model is an abstraction, a simplified representation of part of the real world.
Computer systems are models of the real world - they abstract from the complexity of the real world. Source: http://www.cems.uwe.ac.uk/~tdrewry/modeling.htm
Three Level View • Conceptual level - high level overview description of the universe of discourse (UoD), i.e. domain of interest, • Logical level - is a description of the IS without any reference to the technology that could be used to implement it. • Physical level - is a description of the IS including the technology of a particular implementation. These views are frequently used in data modeling to differentiate levels of abstraction versus detail in the model.
Types of Modelling 1. Process modelling describes the logical (real world) analysis of the process and not just their physical (implementation) level designs. The basic technique of process modelling is functional decomposition, that is the breaking down of a complex problem into more and more detail, in a disciplined way.
Cont … 2. Data modelling is the analysis and design of the information in the system, concentrating on the logical entities and the logical dependencies between these entities. • It is a model which is readily understandable by both developers and users because of its graphical form. • It is independent of any physical implementation, i.e. it is at a logical level • It does not show bias towards particular users or departmental views. The data model can reflect a variety of different views of the data.
3. Object model • Object-oriented concepts unify many aspects of the information systems development process represents data, processes, people and so on, all as objects • It facilitates the realistic re-use of software code and therefore makes application development quicker and more robust • It integrates methods of systems development with the systems context
Objects are characterised by variable attributes (data attributes), procedures (potential behaviour patterns) and behaviour. A Simple Banking System Object Model
Use Cases are used to document system requirements. They provide a useful technique which, in conjunction with Object Modelling, help us to clarify exactly what the system is supposed to do.
Figure: The Overall Process Use Cases and Sequence Diagrams both add to integrity and completeness of the Object Model, and that a good Object Model provides a firm foundation for a good design, and hence a good implementation of the system. Source: Object Oriented Analysis and Design Using UML http://ratio.co.uk/W1.html
Object model (Coad & Yourdon) 1. The ability to tackle more challenging problem situations because of the understanding that the approach brings to the problem situation. 2. The improvement of analyst-user relationships, because the approach can be understood by both equally and because it is not computer-oriented. 3. The improvement in the consistency of results, because it models all aspects of the problem in the same way. 4. The ability to represent factors for change in the model so leading to a more resilient model.
Evolutionary development • Evolutionary development a.k.a incremental development – is a staged or incremental approach that periodically delivers a system that is increasingly complete (i.e. it evolves) over time. • In this approach, development is organized into a series of short, fixed-length (for example, three-week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable partial system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.
Figure: Incremental development Source: http://safari.samspublishing.com/0131111558/ch02lev1sec1
A prototype is an approximation of the IS to be built. Developers can design and build a scaled- down functional model of the desired system then demonstrate this to the users to gain feedback. Types of prototype: A throwaway (or expendable) prototype; An evolutionary prototype. Functional prototypes for demonstrating, testing & evaluating the functionality of a system. Process prototypes for demonstrating, testing & evaluating the processes, sequences, responses, etc. of a system. Design prototypes for demonstrating, testing & evaluating a variety of alternate designs or solutions. Performance prototypes for testing response times, loads, volumes, etc. Organizational prototypes for demonstrating & evaluating different organizational designs, cross-functional work, organizational procesesses, and their integration with information systems. Prototyping
Projects suitable for prototyping Characteristics of a project where it is normally suggested that prototyping is beneficial: • Unclear requirements / Unstable requirements • High innovativeness • High system impact on users / on the organization • Relatively small project size / small number of users / short project duration • Where commitment of users to a project is required.
Rapid Application Development • RAD is a process through which the development cycle of an application is expedited and follows principles and uses techniques including incremental development, timeboxing, MoSCoW rules, JAD workshops, prototyping and toolsets to achieve speedier development.
RAD Aspects Rapid Application Development has four essential aspects: • methodology, • people, • management, and • tools - Computer-Aided Systems Engineering (CASE) tools. Source: http://www.casemaker.com/download/products/totem/rad_wp.pdf
Agile Development • Agile development approach aim at flexible and quick development of software, even where requirements are difficult to define. It emphasizes interactions between people, developing software with less emphasis on documentation, collaborating with customers and responding to change in the development process. • Agile development is an umbrella term used to describe a specific group of methodologies that arose out of a growing discontent with the way software development has been approached for the past 30 years.
Note:- It is important to note that agile development itself is not a methodology. Instead, agile development is a set of fundamental principles about how software should be developed. The best known of a growing number of software development methodologies that subscribe to the principles underpinning agile development include: • Adaptive Software Development (ASD) • Agile Modelling • The Crystal Methodologies • Dynamic Systems Development Method (DSDM) • Extreme Programming (XP) • Feature-Driven Development (FDD) • Lean Software Development • SCRUM Source: http://www.charlesriver.com/resrcs/chapters/1584503645_1stChap.pdf
Web-based Development • A Web-based information system (WIS) not only disseminates information, but also proactively interacts with users and processes their business tasks to accomplish their business goals. Several types of WIS: • Intranets - to support internal work, • Web-presence sites that are marketing tools designed to reach consumers outside the firm, • Electronic commerce systems that support consumer interactions, such as online shopping, and • Extranet - a blend of internal and external systems to support business-to-business communication.
WIS Development Life Cycle • 7 categories of web-based applications: informational, interactive, transactional, workflow, collaborative work environments, online communities/ marketplaces, and web portals. • There are currently several proposed development life cycles for Web-based information systems. WIS development has been regarded as a process, and, as such, it is possible to divide this process into various phases in order to introduce control and minimize risks. Some of the current models of a Web-based information system development life cycle are: Ginige's WIS development process, Pressman's framework of activities for Web applications, Takahashi's and Liang's flow of analysis and design for Web-based information systems, and Fraternali's Life cycle of a Web Application. Source: http://www.umsl.edu/~sauter/analysis/6840_f03_papers/merta/wiscontent.html
Engineering • Engineering - The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. • Legacy systems are systems that have been in operation for some time. They may well perform critical processes, but they are often seen as a problem as they may have high maintenance costs, use obsolete hardware and software, be poorly documented, and lack support people with the knowledge required to maintain them.
Software engineering • Software engineering - The application of a systematic , disciplined, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. • A software engineering project involves people guided by common goals and strategies working with a collection of tools to produce documents and code.
