Week 2 Flashcards
Methodology
Includes techniques to tie together tools and models in design
Allows the break-down into smaller manageable steps
Identifies and defines everything that needs to be done
Identifies resources needed in each step (staff, roles, availability)
Identifies who will do each activity
Provides a basis for project planning
Project Planning
Project phases and activities
Deliverables
Milestones
Models
Used to represent, record, or communicate information
Represent different aspects of real world
Requires abstraction (not detailed)
Models are graphical
Models in information system -> input, output, processes, users, data, objects, interactions, locations
Techniques
Set of guidelines to assist an analyst with completing tasks and activities
Step by step instructions to build models
how to gather information from users
Tools
Software support to create models
artefacts used to aid the designer in modelling and carrying out their techniques
visual modelling applications
word processor
Predictive Approach
Requirements and needs are well defined/ understood
Careful planning
Projects with heavy regulation (banking)
Low technical risk
Requires lots of testing
i.e. Waterfall model
Adaptive
Requirements and needs are uncertain and may be defined after initial development
Adjustments made according to change
High technical risk
Waterfall model
System requirement Software requirement Analysis Design Coding Testing Operation
Characteristics of waterfall model
Most popular
Sequential
Each step is frozen before moving on to the next step
Clear requirements
Easier to implement
Less resources
It does not support changes
Testing done after coding is fully completed
Project Initiation + Planning
A preliminary investigation of the problems, opportunities, constraints and available resources
(cost+benefit)
Define scope (key stakeholders)
Key deliverable (feasibility report)
Analysis
Understand the problems and opportunities
Agree on acceptance criteria (signoff on the system specification)
Assess feasibility again
Design
Generate number of design options, technical, scheduling, economic, operational constraints
Acquire hardware and software (but nowadays prefers vendor or cloud)
Design interfaces, databases, network requirements
Specify integration requirements and software requirements (programs)
Implementation, Testing & Deployment
Build/modify databases and networks as required
Complete coding
Perform various testing
Prepare users for new system (documentation, acceptance testing, training)
Finalise system and technical documentation
Install and deploy the system
Alpha testing
testing to identify performance issues and bugs
conducted by testers
Beta Testing
testing by limited amount of real users
Performance Testing
process used for testing the speed, response time, stability, reliability, scalability and resource usage of a software application under particular workload.
Unit Testing
individual units or components of a software are tested. The purpose is to validate that each unit of the software code performs as expected.
Integration Testing
where software modules are integrated logically and tested as a group. A typical software project consists of multiple software modules, coded by different programmers.
Usability testing
user experience, ease of use of the system
Support Phase
Hypercare support phase right after deployment
It includes activities to upgrade or maintain the system after it is installed
Staging environment
Environment that replicates production environment
Testing environment
Testing environment , tests individual units
Adaptive SDLC Approaches
Iterative (able to change)
Project can be refined by adjusting plans and models as project progresses
Conduct post -mortem (for learning)
Agile
Guidelines for information system development in an uncertain and rapidly changing environment
Agile manifesto
Focuses on individuals vs process
working software vs documentation
Collaboration vs negotiation
Responding to change vs following a plan
study scrum flashcards
study scrum flashcards
eXtreme Programming (XP)
Focusses on best practices of software development
Communication -> open communication
Simplicity -> simplest method that it will work
Feedback -> constant and meaningful feedback
Courage -> to do the right thing i.e. throw away bad code
Respect -> team members should respect each other
Rules of eXtreme Programming: User stories
Use cases but written by customers about what the system needs to do for them
Rules of eXtreme Programming: CRC Cards
Class, responsibilities and collaboration
Rules of eXtreme Programming: Spike
Simplest possible program to address only the problem at hand
Rules of eXtreme Programming : System metaphor
Using terms understood by both developers and customers
Rules of eXtreme Programming: Pair programming
Code created by two people sharing one computer, to increase software quality
Rules of eXtreme Programming: Refactoring
Removing redundancy and unused functionality, complexity
Rules of eXtreme Programming: Others
Test-driven development
Continuous integration
Customer involvement
