Business Information Management PDF

Business Information Management Dr. Michael P. O’Brien Module: MI4007 Week 10 (Lecture 1) 1 Systems Development The systems development life cycle, also referred to as the application development life-cycle, is a term used in systems enginee...

Business Information Management Dr. Michael P. O’Brien Module: MI4007 Week 10 (Lecture 1) 1 Systems Development The systems development life cycle, also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system A software lifecycle model is a standardised format for – planning – organising, and – running a new development project. Definition: A (software/system) lifecycle model is a description of the sequence of activities carried out in an SE project, and the relative order of these activities. 2  Lifecycle Models Hundreds of different kinds of models are known and used. Many are minor variations on just a small number of basic models. Software Engineering projects usually live with a fixed financial budget. Additionally, time-to-market places a strong time constraint. There will be other project constraints such as staff. 3 Project Constraints designers programmers managers money staff Project constraints computing resources time 4  Project Planning Project planning is the art of scheduling the necessary activities, in time, space and across staff in order to optimise: – project risk [low] – profit [high] – customer satisfaction [high] – worker satisfaction [high] – long-term company goals 5 Project Planning A project plan contains much information, but must at least describe: – resources needed (people, money, equipment, etc) – dependency & timing of work (flow graph, work packages) – rate of delivery (reports, code, etc) It is impossible to measure rate of progress except with reference to a plan. 6  Project Planning Software 7 Project Visibility Unlike other engineers (e.g. civil, electronic, chemical, etc.) software engineers do not produce anything physical. It is inherently difficult to monitor a Software Engineering project due to lack of visibility. This means that SE projects must produce additional deliverables (artifacts) which are visible, such as: - Design documents/ prototypes - Reports - Project/status meetings - Client surveys (e.g. satisfaction level) 8  Systems Development Systems Development is notoriously difficult, and fails in terms of Time Cost Functionality Recent Standish Report, USA: 32% of projects successful 44% “challenged” 24% failures Estimated cost in the US (alone): $78b 9 Systems Development NASA Mars Observer Spacecraft, 1993 Lost, presumed “burned up” in the Martian atmosphere Therac-25 medical radiation unit Traced to a software failure Used to treat cancer: tragically Two teams used two different units of several patients died of measurement: inches / cm overdoses. New software to handle dosage bypassed rigorous tests because it was “only an upgrade” Denver Airport Baggage Handling System Investigation revealed litany of 2 years late failures $500m cost overrun Extremely complex system Lots of (physical) problems e.g. Bags “falling off” conveyors Baggage carts “overflowing 10  Systems Development “It cost too much” “It took too long” “This isn’t the system we want” “Everything has changed now.” Management “Its too hard to use” “It isn’t useful” “I don’t like it” Users Developers “We built what they said they wanted.” “We didn’t have enough time” “We said it was impossible – Nobody listened” 11 Systems Development Poor communication Systems Development Methodologies Poor analysis or design Project Management Poor management Techniques 12  Systems Development Phases Activities Stakeholder Input 13 Initiation Initiation Phase Purpose: Decide on System Inputs: Business Rationale for System Process: Feasibility Planning, Project Planning Outputs: Go/Stop Decision, Project Plan 14  Analysis Analysis Phase Purpose: Define Requirements Inputs: Business & User Requirements Process: Determine Requirements Outputs: Requirements, Goals, Testing Plan 15 Design Design Purpose: Specify the system Inputs: Requirements Process: Evaluation of Design Options Outputs: System Architecture, System Design 16  Development Development Purpose: Implement Design Inputs: Design Documentation Process: Software Engineering Outputs: Information System 17 Implementation Implementation Purpose: Deploy System Inputs: System Components, Test Plan Process: Installation, Training, Data Migration Output: Live, Active System 18  Maintenance Maintenance Purpose: Keep system running Inputs: System, New requirements, User Input Process: Monitoring, Software Engineering Outputs: Patches, Training 19 Lifecycle Models The waterfall model is the classic lifecycle model - it is widely known, understood and used. In some respect, waterfall is the ”common sense” approach. Fundamentally, the waterfall’s model of sequential progression is too limiting, particularly for large projects where each stage can take months or years. 20  Lifecycle Models Prototyping: Developing a small part of the system at a time, and building the system incrementally. Tends to be Rapid: Prototypes are rapidly created and destroyed Simple: Skeleton applications are produced to give a feel for the overall system Iterative: Protoypes are produced rapidly and improved upon rapidly Incremental: Each prototype incorporates feedback User Centered: Users are constantly involved in development 21 22