Systems Development Course Review

This note is for the course from Monash University - FIT2001.

S1: Nature of Systems Development

Information systems

What are the information systems?

Introduction

Information systems: a integrated set of components for collecting, storing, and processing data and for delivering information.

The main components of an information systems are - people, procedures, hardware, software, databases, data warehouses and telecommunications.

Sample question

Briefly discuss why the Student Enrolment system is an information system and, describe its key components.

A:

• Reason:

  Collecting: collect students’ enrolment data,

  Storing: store the students’ enrolment data

  Processing: to know whether you are on track on complete that course.

  Delivering: give a list of classes / lecturer could see who enrolled his/her course.

• Key components:

  people: adamic stuff -> put the courses in the system

  procedures: students input data into the system and the data will be check if valid? If the chosen unit matches students’ major field?

  hardware: laptop, PC, printers, screens…

  software: written programs, OS

  databases: student information will be stored in the databases.

  telecommunications: network

Systems Development Life Cycle(SDLC)

Phases in the SDLC - Key activities(IADI)

phase 1: Initiation

key activities

• Review and priorities project requests

• Assess project feasibility

• Develop the project plan

phase 2: Analysis

key activities

• Determine detailed user requirements.
• Create system models to confirm requirements and for design.
• Perform Build vs Buy analysis.

phase 3: Design

key activities

• Define technical architecture.
• Produce technical specs.
• Create database.

phase 4: Implementation

key activities

• Build, Test, Validate.
• Conduct Integration, System and Acceptance testing.
• Create User Docs, Train users.
• Install, Deploy new system.

phase 5: Support

• Conduct post-implementation system review
• Identify errors and enhancements
• Monitor system performance

Sample Question

You are chatting with a friend about your job as an IT Developer, and they ask for a brief description on how IT systems are developed. Briefly describe the key phases of IT systems development, and the importance of each phase in the development process. (Seminar 1)

A:

• Initiation:
  • assess whether project is feasible.
  • whether you can build the system on time within the budget.
  • Is the expertise available?
  • Importance: It determines whether you can go ahead or not, otherwise you waste your money.
• Analysis
  • Determine detailed user requirements.
  • Create system models to confirm requirements and for design.
  • Perform Build vs Buy analysis.
  • Importance: it is vital that you demonstrate to the client that you understand their requirements otherwise you can’t build the system they want to pay for.
• Design
  • Define technical architecture.
  • Produce technical specs. Interface Design/ prototypes/ Security/ network
  • Create database.
  • Importance: easy to maintain
• Implementation
  • Build, Test, Validate if the system works.
  • Conduct Integration, System and Acceptance testing.
  • Create User Docs, Train users.
  • Install, Deploy new system.
  • Importance: developers know what they’re building and users know that they are using. users need to know how to use the system.
• Support
  • post-implementation review
  • Ready to fix errors, handle the system.
  • Importance: be able to handle the system, you can get benefit and opportunity to reflect and learn.

System developers - Critical skills for every role

Introduction

• Understanding business - awareness and sensitivity to the business processes
  and needs that require technology in the first place
• Broad and up-to-date understanding of technology – can be invaluable in
  creating the ‘best’ solutions for the organization
• Multiple Perspectives - The ability to understand that there are multiple
  perspectives to solving a problems is required to find the best solution
• People/Soft Skills - the ability to interact with other people and to be a part of a
  team
• Continuous Learning – essential in a high-change industry, like IT

Sample Question

You are attending a job interview as a System Developer. What skills are you going to showcase in your interview? (Seminar 1)

S2: System Development Approaches, Agile Software Development, Stakeholder management

Approaches

• predictive

  • requirements -> well understood&defined
  • low tech risk

• adaptive

  • requirements&needs->uncertain
  • high tech risk

Waterfall

• sequential stages(no overlap and iteration)
• strong emphasis on planning and specification development
• works well for clearly defined projects

Aglie

• value(RVVV)
  CP/IPT/WCD/CCCN

  • responding to change over following a plan
  • value interactions and individuals over process and tools
  • value working software over comprehensive documentation
  • value costumer collaboration over contact negotiation

• 12 Principles

  • software is the primary goal
  • next effort is the secondary goal
  • …

• SCRUM(Agile frameworks) artifact

  • product backlog

    • the single source of requirements
    • cumulative list of the desired deliverable for the project - every feature, enhancement, bug fix, documentation requirement, every bit of work required by the team
    • prioritised to maximise value

  • sprint backlog

    • a list of tasks the team must complete to deliver an increment of functional software at the end of each Sprint
    • Once decided Team owns the Sprint Backlog - only they can decide on scope change.

  • sprint burndown charts

    • shows the total estimated work remaining for the entire forecasted sprint backlog against time

  • task board

    • allows visibility and transparency across the project
    • display the live status of team work and focus
    • Most have - Backlog, to-do, doing and done status

stakeholder management

• define

  • internal stakeholders

    • within the organisation

  • external stakeholders

    • outside the organization

  • operational stakeholders

    • regularly interact with the system

  • executive stakeholders

    • don’t interact directly but use the information or have a financial interest

• **prioritise and understand your stakeholders

  -

S3: Investigating System Requirements/ Information Gathering Techniques

requirements gathering

• investigating requirements using a range of techniques
• developing a deep understanding of the business domain
• defining what the solution needs to be to meet the requirements
• requirements must be verified by the client

requirements

• functional requirements

  • represents the activities a software system must perform
  • business functions that end-users carry out
  • expressed in terms of models

• non-functional requirements

  • represents other characteristics from a software system
  • like constraints
  • performance goals(speed)

information gathering techniques

• Interviewing users and stakeholders

  • efficient way but time-consuming

  • how to prapre

    • set clear objectives & what information is needed

    • select appropriate stakeholders to interview

    • determine one-on-one/group interview

    • consider outside information - reports, forms, etc

    • review related documents and develop an agenda

    • documents objectives, nothing forgotten, logical progression

    • avoid long interviews - stakeholder do not have much time/ choose several shorter interviews

    • planning- interviewees has been sent Location, time, objectives & list of questions

    • send reminders

    • arrive early

    • room is prepared for the interview

    • decide on a documentation method(get permission)

      • take notes
      • video taped
      • recording

    • follow up as needed - in future meetings or interviews

• distributing and collecting questionnaires

  • online, paper-based or email

  • advantages

    • cover a wide spectrum of people
    • faster responses
    • low costs of distribution
    • good when people are widely dispersed
    • can give a preliminary insight into business

  • disadvantages

    • low response rate - not many people are willing to respond
    • not well for gathering the detailed information

• Reviewing existing reports, forms and procedure descriptions

  • existing business documents and procedures within organisation

    • obtain preliminary understanding of precess
    • identify business rules, discrepancies, redundancies
    • be cautious of outdated material
    • can help guide interviews

• Observation

  • avoid hawthorne effect

    • also referred to as the observer effect refers to a phenomenon, whereby workers :

      • improve or modify an aspect of their behaviours/activities
      • or STOP WORKING in response to the fact that they are being observed

• Researching vendor solution

  • many problems have been solved by other companies - have a look around for good ideas

  • positive contributions of vendor solutions

    • frequently provide new ideas
    • may be the state of the art
    • cheaper and less risky

  • danger

    • may need to purchase solution before understanding problem
    • vendor support may not be there in the future
    • upgrade issues
    • may not address all business requirements

• Prototyping

• story-writing workshops

Investigating/documenting system requirements

User Stories, Activity diagrams

• Models

  • why do we use them?

    • The model serves as an abstraction - an approximate representation of the real item

    • A simplified picture of complex reality

    • Reasons/advantages for modelling in system analysis

      • reducing complexity of systems to be built by abstraction
      • communication with other development team members
      • communication with stakeholders/users
      • learning from the model process
      • documenting all the detailed of requirements for future maintenance/enhancement - represents some key aspects of the system being built

• User stories

  • define - what are they?

    • short, simple description of a product feature - told from the perspective of the user who wants that feature
    • They go into product backlog

  • reason - why User Stories

    • encourages user communication and collaboration and real-time feedback
    • focus on end user value
    • planning is simplified - if it’s too big, you can’t estimate it
    • avoids locking in design detail too early - focus on WHAT - leaves the technical aspects to the developers, testers, etc.
    • Users do not need to be trained to understand User Stories
    • never out of date, just in time
    • eliminates weighty documentation - create what you need to deliver the story
    • easier to communicate with users

  • how do you write

    • As xxxx I want xxxxxx so that xxx
    • exam included

  • good stories?(INVEST)

    • independent

      • not depend on other stories

    • negotiable

      • leave room for negotiation

    • valuable

      • gives value to the customer

    • estimable

      • should have enough information to be estimated

    • small

      • small enough to fit within a sprint

    • Testable

      • includes acceptance criteria to test that customer needs met.

• Activity diagrams

  • define

    • a technique to describe a procedural logic, business process, and workflow.

    • describes

      • user activities
      • the person who does each activity
      • the sequence of activities

S5: Use Case Diagrams

Use Case Diagram

• Actor

  • Primary Actor

    • using the system to achieve a goal

  • Secondary Actor

    • The system needs assistance to achieve the primary actor’s goal(s)

  • generalisation

    • inherits the behaviours of its parents and adds new behaviours

Use Case Description

• Identify the Actors
• identify the goal
• identify the pre-conditions
• define the Post-conditions
• describe Main Flows
• describe Alternative Flows

S6: Domain Class Modelling

be able to draw

S7: Prototyping

Usability of systems

Prototyping

• Definition of Prototyping

  • a process of quickly mocking up the future system functionality
  • use visuals to describe how a system should behave and look
  • can be horizontal or vertical
  • can be experimental or evolutionary

• Advantage of Prototyping

  • explore the idea before you invest in them(improve communication, reduce risk)
  • saves time and money
  • proof of concept
  • technical and design exploration

• Disadvantage of Prototyping

  • make the users think the system is developed
  • create a system that does not scale
  • Waste time(as developers spend much time making throw away prototypes looks good)

Usability

• Definition

  • the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction

    • Effectiveness: accuracy and completeness
    • Efficiency: resources expended in relation to effectiveness
    • Satisfaction: the comfort and acceptability of the work system to its users.

• why is it important

  • help improve user effciency
  • can make users feel more in control
  • help improve sales of products
  • help improve usage of the system
  • can improve user satisfication

• usability of an interface design
  evaluating usability

  • Learnability: how easy is it for users to accomplish basic tasks at the first time?
  • Efficiency: once users learned the design, how quickly they can perform the task
  • Memorability: When users return to the design after of a period of not using it, how easily they can re-establish proficiency
  • Errors: how many errors do users make?how severe are these errors? How easily can they recover from the errors?
  • Satisfaction: how pleasant is it to use the design

• type of usability of evaluation

  • formative evaluation

    • Users experience prototypes and identify usability problems
    • Evaluation by HCI expert

  • Summative evaluation

    • takes place post development
    • quantitive results collected

S8: Interface Design Guidelines and tips

guidlines

• Ben Shneiderman’s 8 Golden rules

  • Ben Shneiderman’s 8 Golden rules

• Jakob Nielsen’s 10 heuristics

• Don Norman’s Guidlines

personas

• why important

  • Build Empathy

    • Help users seem more real - designers empathise and build for their users

  • Provide direction for making design decisions

    • help focus design decision on users

  • communicate Research Finding

    • Team on the same page communicate the information in an easy to understand format

S9: Use Case Realisation

Quality of design models

• cohesion measures the consistency of functions in a class

  • a single focus of class

  • a single focus of the methods in a class

  • no methods with multiple functions

  • low cohesion(Tight)

    • hard to maintain
    • hard to reuse
    • hard to understand

• coupling

  • Qualitative measure of how closely classes are linked.

  • low or loos coupling make system easier to understand and maintain, minimal ripple effort

  • Tight coupling often leads to low cohesion

    • increase the extent to which objects are independent
    • can causes ripple trough effects
    • reduces the ability to reuse parts of the system
    • hard to maintain

Design Class Diagram

• design and document the programming classes that will be built for the new system
• shows set of problem domain classes and their association relationships

S10: Security & Testing

Testing

• definition

  • represents the process of examining a component, subsystem, or system to:

    • if it determines any defect
    • uncover design flows and limitations
    • verify that it is “fits for purpose” and meets the needs of the Business/End User
    • reduce the risk of failure

• Testing process in different development approaches

  • Waterfall

    • generally all testing and quality control points late in the project

  • Agile

    • Testing is integrated throughout the lifecycle; testing the software continuously throughout its development
    • NO a separate test phase
    • Developers write automated repeatable unit tests to validate their code
    • Supports the principle of small, iterative, incremental releases.
    • Testing is done as part of the build. Ensure that all features are working correctly each time the build is produced.
    • integration is done as you go
    • the purpose of these principles is to keep the software in releasable condition thought the development, so it can be shipped whenever it’s appropriate.

• Testing methods

  • Black Box Testing

    • without reference to the internal structure of the component and system

  • White Box Testing

    • uses an internal perspective of the system to design test cases based on internal structure

  • Grey Box Testing

    • increase testing coverage

• Testing type

  • functional testing
  • regression testing
  • static & dynamic testing
  • performance & load & stress testing - usability testing
  • accessibility testing
  • security testing
  • Backup&Recovery testing

S11. Implementation & Maintainance

Implementation phase activities

• implementation Planning

  • review acceptance Checklist, Prepare Implementation Schedule

• Build the system or buy the system

  • will result in a varied implementation path

• test the system

  • System Testing(functional and performance) Acceptance Testing

• finalise documentation

  • system documentation
  • user documentation

• get ready for the system to go into Production

  • data conversion
  • configure the production environment
  • conduct trainning

• Deploy the system

  • install/deploy the system, Monitor Operations, benchmark Testing, tune the system

• wrapup

  • Opperation handover
  • transition support
  • system closure
  • post-implementation review

data conversion

• Original
• consolidation
• Cleansing
• Update
• Final Load

trainning

• consideration

  • users, number of users
  • existing skills level - on-going level
  • who conduct the meeting
  • when/where training should be conducted
  • training documentation
  • need supported User Manager who committed allocating time for training

deployment

• Direct deployment

  • install a new system

  • This approach is meaningful when:

    • the system is not replacing any other system

    • – the old system is judged absolutely without value

    • – the new system is completely different from the old and comparisons would be meaningless

    • – the old system is either very small and/or very simple

  • advantage

    • Simple, fewer logistic issues to manage, costs minimised

• Parallel deployment

  • old and new systems both operate for an extended period of time

  • advantage

    • Risk low if problems occurs – continual backup

  • disadvantage

    • High cost: increased personnel, extra space, increased managerial and logistic complexity

• Pilot deployment(multiple locations)

  • old and new systems operated concurrectly

  • only part of organisation tries out the new system

  • The pilot system must prove itself at the test site

  • advantage

    • Risks relatively low if problems occur
    • Errors are localised to pilot site
    • Can be used to train users before implementation at their own site

  • disadvantage

    • Lack of consistency between different parts of the organisation

• Phased deployment(multiple functions)

  • A New system installed in series of steps or phase, where each phase adds components to the existing system

  • advantage

    • Reduces risk because phase failure is less serious than system failure
    • Lower costs for earlier results
    • Benefits can be realised earlier
    • Rate of change minimised for users

  • Disadvantage

    • Multiple phases cause more activities, milestones, and management complexity for entire effort
    • Close control of systems development is essential
    • Costs associated with the development of temporary interfaces to old systems
    • Limited business applicability

Maintenance/closure

• Corrective maintenance

  • corrects analysis, design, and implementation errors
  • focus on moving defects

• Adaptive maintenance

  • to satisfy changes in the new environment, changing business needs or new user requirements

• Perfective maintenance

  • to enhance performance, maintainability, usability
  • To meet user requirements not previously recognised or given high
    priority

• Preventative maintenance

  • identify and fix any
    potential problems noted while fixing other errors

Change Management system

• manage change effectively
• reduce the confusion and complexity of
  developing and maintaining systems

why post implementation review important

• post implementation analyses what went wrong and right with a project
• compare costs of development and operation against original estimates
• look at original requirements and evaluate how well they were met
• compare original and actual benefits
• new system reviewed to see whether more of original or additional benefits can be realised