Systems Development Course Review
2022-06-09 09:43:07 # others

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

S1: Nature of Systems Development

Information systems

What are the information systems?


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.


  • 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)


  • 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


  • 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
  • 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


  • predictive

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

    • requirements&needs->uncertain
    • high tech risk


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


  • value(RVVV)

    • 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


  • 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


  • 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)


  • 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


  • Ben Shneiderman’s 8 Golden rules

    • Ben Shneiderman’s 8 Golden rules
  • Jakob Nielsen’s 10 heuristics

  • Don Norman’s Guidlines


  • 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


  • 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


  • 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


  • 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


  • 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
  • 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