Lecture 3 - Systems Development
Lecture 3 - Systems Development ACC1006
Popular in Accounting Information Systems
Popular in Accounting
This 7 page Class Notes was uploaded by Wai Chuan on Sunday August 16, 2015. The Class Notes belongs to ACC1006 at National University of Singapore taught by in Summer 2015. Since its upload, it has received 69 views. For similar materials see Accounting Information Systems in Accounting at National University of Singapore.
Reviews for Lecture 3 - Systems Development
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 08/16/15
Chapter 5 Systems Development Lecture 3 51 What is svstems develonment Defined 0 Systems development or systems analysis and design 0 Creating and maintaining information systems 0 Concerns information systems not just computer programs 0 5 components hardware software data procedures and people SD is not iust for Techies 0 Need business knowledge and management skills Understand group dynamics HR expertise understand business activities S are never off the shelf 0 It involves people and procedures Procedures must be constructed or adapted to fit its business and people 0 Users must take ownership of their systems I Ensuring effective procedures I Ensuring training of personnel so that they use S effectively I Ensure buyin o Offthe shelf is expensive and need to be modified 0 For isolated scope ie standalone systems off the shelf might be feasible But in accounting systems there are many interfaces 0 CASE ERP I Our ERP had to be tailor made to suit local traffic conditions Off the shelf systems or equipment would not be adequate I Perceived reliability Users must have confidence in the system I Motorists feedback was taken seriously 9 Buy in I Educate the users to remove apprehension I Fair to make motorists pay each time they enter area 0 CASE TAURUS I To make the entire process more efficient and time saving through paperless trading I 11 years late and 132 times over the budget I Causes 0 Unsuitable database management system from Vista Concept 60 mods 0 System ended up intending to do quotall things to all men 0 Many committees were formed Poor communication and accountability 0 Requirement creep Ineffective project controls Requirement creeps was allowed because of powerful interest groups and lack of skills to deal with these interest groups 0 CASE Nike s supply chain crisis Supply and demand didn t match I Poor integration of ERP SCM and CRM I Lack of training I Pilot test not properly executed I Requirement analysis not properly done 52 Whv is SD difficult gnd riskv How difficult risky Only around 20 of all IT projects are finished in a timely manner 521 Difficulty in determining requirements 0 Must create environment where difficult questions are asked and answered I What features do you want Do you really need them What kind of controls do you want What functions should it have What data do you have What information do you want provided Just enough and not as much as possible 0 Most impt stage Subsequent steps are based on this 0 Collection of information about the current system and how users would like to improve their performance with new information system 0 Eg Taurus 522 Changes in requirements as project develops Scope creep o What can management do I Stop work and rebuild Run over time I Just finish Unsatisfactory and requires maintenance 523 Difficulties involving scheduling and budgeting o How long to build it Create data model Build database applications Testing Develop and document procedures Training 0 How much labor hours and cost 0 Financials Costs and benefits ROI 0 based on the firm s past experience 524 Changing tech 0 New tech as project develops Stop project and switch to new tech Orjust finish 525 Diseconomies of scale As development teams become larger the average contribution per worker decreases Brooks Law quotAdding more people to a project makes the project later Increased coordination needed quotRamp up time New people need training by existing team members who must drop productive tasks 0 Communication overheads increase number of different communication channels increases along with the square of the number of people All need to be kept in sync 0 Some tasks simply can t be speeded up 526 Other reasons 0 Unclear objectives and goals resulting in scope creep and feature creep 0 Lack of executive support and user involvement 0 Communication failure 527 Is SD really so bleak 0 Yes and no All these challenges exist Every development project must overcome them 0000 53 SD Life cycle jSDLCj l3IIIIsiIriIess Fianning V Process I System IDIefi niitieln Project 5 Pllan Approved User I Requirements Component Design System Design System Maintenance 1 Pmbllem er Need for E hange h SETS Business Planning 0 Comprehensive analysis of the business goals objectives strategies 0 Output Identifies the need for a new system Systems definition 0 Management s statement of objective and goals for new system 0 Output is project plan Requirements analysis 0 Developers identify the particular features and functions of the new system 0 Output Approved user requirements Component design hardware software network Implementation 0 Purchase build test and convert to new system System maintenance fix or enhance 0 Repair add new features maintain Repeat SDLC 54 System Definition 39 Planning quot v 39 39 39 39 39 System Need l PWEESS Definition ijea 3973 39 I Define system Plan goals and scope 39 Assess feasibility cost schedule technical organizational Form project team Plan project Define system goals and scope 0 Define system goals for new system I Facilitate competitive strategy I Improve decision making I Create quality relationships with quality customers 0 Define scope for new system I By customers users involved business processes impacted physical location deliverables external and internal technical structures Functionalities I Clear definition of scope simplifies Requirements determination and Coordination Assess feasibility 0 Cost and schedule feasibility is to eliminate obviously infeasible ideas 0 Cost feasibility I Back of the envelop Cost benefit analysis approximate past experience I Consider cost of previous projects operational and labor costs 0 Schedule feasibility I Ball park estimate with schedule padding 0 Technical feasibility I Existing IT expertise or IT resources hardware and software 0 Organizational feasibilityoperational feasibility I Fit with customs culture charter legal requirements of organization I Fit with current working environment i e resistance from users Form proiect team 0 Personnel I Manager or mangers for larger projects I System analysts 0 IS professionals who understand both business and tech 0 Active throughout SD process 0 Tell organizations which computers and software packages to buy 0 Integrate work of programmers testers and users I May include hardware and communications specialists database designers and administrators and other IT specialists 0 Team composition changes over time I Requirements definition Systems analysts I Design and implementation Programmers testers and database designers I Integrated testing and conversion Testers and business users 55 Requirements ADM Saystent D39E n quotmm Project Approved User if Requirements Importeth In In Primary purpose Determine and document specific features and functions of new system Interviewing users Understanding the users needs and expectations Examine the existing systems the current forms and reports and ask ourselves what do we want in the new system Must consider requirements for all 5 IS components eg hardware procedures and people Expensive and difficult Mistakes made here can be costly resulting in 1 user frustration 2 interface unfriendly 3 solves wrong problems 4 high maintenance cost Obtain user approval Let users review and approve specified requirements before continue 56 Component design Hardware design 0 Determine specifications for required hardware 0 Purchase it lease it or lease time from hosting service 0 Look at the firm s existing technology basis Software design 0 Offtheshelf OR custom developed Database design 0 Convert data model to a database design Procedure design 0 Design procedures for Users and operations personnel 0 Developed for Normal backup failure recovery procedures I Ensure that in the event of blackoutsudden shutdown the system doesn t fail Graceful degradation fault tolerant system No single point of failure Fault isolation to the failing component Fault containment to prevent propagation of the failure Availability of reversion modes Multiple layers of redundancies Design of iob descriptions o Duties and responsibilities for newjobs and revised jobs coordinated with human resources policies 57 Implementation System testing 0 Test plan I 1 What is to be tested number of features to be tested I 2 test cases and the number of test cases 0 A test case is just a set of conditions or variables under which a tester will determine whether an application or software is working correctly or not the more test cases conducted the better it is But we cannot construct the universe of test cases I 3 who will do the testing I 4 How much time to devote to testing 0 Unit level Testing I Discover bugs here and fix them O O O I Focuses on testing each unit of the code System Test I Integration testing testing integration of code regression testing I First level where the system is tested as a whole I Tested to verify if it meets the functional and technical requirements I Tested in an environment that closely resembles the production environment where the application will be finally deployed I Enables us to test verify and validate both the Business requirements as well as the Application Architecture Product Quality Assurance PQA I Constructs test plan with advice and assistance of users I Perform testing and supervise user testing activity I Users should be involved in PQA 0 Developing test plans and test cases 0 Final say on whether system is quotproduction ready Beta testing I Last stage of testing I Complete fully functioning I Allowing future users to try out the system on their own I Discovery and sometimes removal of vulnerabilities 0 Can use software scanners but they cannot replace human judgment 0 Will yield false positives and limitedscope view of problems present 0 For operating systems Constant vigilance including o careful system maintenance eg software patches 0 best practices in deployment eg firewalls and access controls 0 auditing during development and throughout deployment lifecycle System Conversion After integrated testing install the new system 0 O O O 0 Pilot I Implement entire system in limited portion of business I May use system for selected customers I Advantage limits exposure to business if system fails Phased I System is installed in phases or modules I Each piece is installed and tested Parallel I Complete new and old systems run simultaneously I Very safe but expensive Plunge or direct I Shut off old system and start new system I High risk if new system fails no old system to fall back on I Only used if new system is not vital to company operation Design Implementation Unit testing Hardware Hardware specifications Obtain install test hardware Software Off the shelf or License and install Design alterations and custom programs Write alterations and custom programs as necessary Test programs Data Design database and related structures Create database Fill with data Test data Procedure Design user and ops procedures Document procedures Create training programs Review and test procedures People Develop user and ops job descriptions Hire and train personnel Integrated test and conversion 58 Svstem Maintenance System Definition A Plublum or New in Change Usvls Two types 0 Adaptive Maintenace adapt to change in env I Requirements that are not identified during requirement analysis phase I changes in the input data the system environment and output formats 0 Corrective maintenance Fix errors Prioritisation of System problems according to severity 0 Failure Difference between what a system does and what it is supposed to do Minor enhancements 0 Service pack Collection of updates fixes and enhancements to an application I May contain updates for system reliability program compatibility security and efficiency among others I Periodic update that corrects problems in one version of a product 0 Patch an update that occurs between service packs I Piece of software designed to fix problems with or update a computer program or its supporting data I Includes fixing security vulnerabilities and other bugs and improving the usability or performance I Applied to all copies of a software product I Shipping software with defects is software industry practice They only remove the most serious problems The rest they don t care for now I Poorly designed patches can sometimes introduce new problems Maior enhancements 0 Usually result in new version of software product 0 Hardware and database failures or enhancements Maintenance work is based on existing software vs development work which creates new software Revolve around 0 understanding the existing software code related documents understanding the effects of change making the changes both to the code and documents testing the new parts changes resetting of the old parts that were not changed I Regression testing Executing old test cases to test that no new errors have been introduced Complexity of maintenance Neglect of maintenance concerns during development 0000 59 IT Proiect faiure causes and reasons Scope and requirement creeps 0 Some event makes the cost of change exponential and all progress stops 0 Events like losing a key team member adding team members to accelerate production unforeseen difficulties with technology choices unforeseen requirements and major changes in target audiencemarket o Project 90 done Team making steady progress but never finishes the required features because of a gradual rise in the cost of change o Often unavoidable because the riskiest features are often put off until last These features often require so much complexity that their solutions overwhelm the development process 0 Proper risk mitigation is essential Software bugs and design defects will always be there Endless software testing and quality assurance can result in exponential cost increase 0 Software testing is not mature yet 0 Typically more than 50 percent of the development time is spent in testing Failures usually discovered only after it is too late Most software projects can be considered at least partial failures because few projects meet all their cost schedule quality or requirements objectives
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'