www.it.monash.

edu
COMMONWEALTH OF AUSTRALIA Copyright Regulations 1969

www.it.monash.edu

WARNING This material has been reproduced and communicated to you by or on behalf of Monash University pursuant to Part VB of the Copyright Act 1968 (the Act). The material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice.

FIT2001 Systems Development: campus Week 1 Lecturer Sections 2012 by Thomson Course Technology. All rights reserved.

The nature of systems development

www.it.monash.edu

www.it.monash.edu

Overview of todays lecture

Introducing the academic staff Unit objectives Semester structure Text book and workload Assessment
Plagiarism

Teaching Team
Lecturer: Tutors:

The nature of systems development

www.it.monash.edu

www.it.monash.edu

Lecture and studios

Lecture

Common Core
FIT2001 is a common core unit. The common core is a set of units that will be taken by all undergraduate students studying degrees with the Faculty of Information Technology. It represents the fundamental body of knowledge that we believe all IT professionals require.

Studios

www.it.monash.edu

www.it.monash.edu

FIT2001 Unit Objectives

Knowledge and understanding of The roles of systems analysts and designers in agile system development, the criteria that can be used to evaluate the quality of a model of a system, the purpose of different types of models in the UML, and the role and application of automated tools in systems modelling.

FIT2001 Unit Objectives (Cont.)

Developed attitudes that enable them to:
appreciate that a range of valid solutions exist for any given problem. Demonstrated the communication skills necessary to: explain the interdependence and relationships between all stake-holders in the systems development process, and create and understand RFP documents.

www.it.monash.edu

www.it.monash.edu

FIT2001 Unit Objectives (Cont.)

Developed the skills to:
interpret and evaluate systems analysis and systems design models created using UML create analysis and design models using the main elements of UML namely class, use-case, sequence and robustness diagrams; create system test plans and test cases, and conduct system testing; create and evaluate models and prototypes of a user interface using storyboards and wireframes; apply problem solving techniques at different levels of abstraction and understand the effect this may have on a system specification.

FIT2001 Unit Objectives (Cont.)

Practical skills (Cont.)
Create analysis and design models using the main elements of the unified modelling language (UML) Develop and practice the skills and competencies necessary to undertake a requirements analysis for a business application Apply problem solving techniques at different levels of abstraction and understand the effect this may have on a system specification

www.it.monash.edu

www.it.monash.edu

Textbooks
Recommended texts:
Satzinger, J. W., Jackson, R.B., Burd, S.D. and R. Johnson (2012) Systems Analysis and Design in a Changing World, 6th Edition, Thomsen Course Technology. Rosenburg and Stephens (2007) Use case driven object modeling with UML theory and practice. Apress. (free e-copy available) Refer to unit information guide

Systems Analysis and Design in a Changing World

The library has an e-version you can download for free.

Use case driven object modeling with UML theory and practice

www.it.monash.edu

www.it.monash.edu

Anticipated Workload
2 hour lecture 2 hour per week workshop/tutorial session 6 hours per week preparation and project work 2 hours per week reading

Assessment
40% - Assignments
You must do 2 assignments.
Three assignments available, each worth 20%. Can do more than 2, your best 2 will count.

60% - Examination
Three hour, closed book exam, scheduled during the normal exam period.

www.it.monash.edu

www.it.monash.edu

Assignments and due dates

1 Domain model with UML diagrams, March 30th 2 Design specification and test planning, May 18th 3 Request for proposals and interface prototyping, May 25th

Plagiarism/cheating
The University and the Faculty have various policies regarding plagiarism that you must make yourself familiar with.
http://www.infotech.monash.edu.au/about/committeesgroups/facboard/policies/academiccheat.html

www.it.monash.edu

www.it.monash.edu

Lecture schedule
Site includes downloads, forums, campus specific information Make full use of this system to get the most out of the unit 1. The development environment 2. Domain modelling with UML 3. Prototyping in analysis and design 4. Process modelling with use case diagrams 5. Interface design principles 6. Usability testing 7. Principles of good design 8. Use case realization with sequence diagrams 9. The requirements specification and RFPS 10.Use case driven testing 11. Requirements gathering and stakeholder expectation management 12. The implementation and support phase

www.it.monash.edu

www.it.monash.edu

This weeks learning objectives

On completion of this your study this week you should aim to be able to:
Describe the role of the systems analyst in a systems development project. Explain the importance of technical, people business and analytical skills for an analyst. Describe the various job titles that are applied in different work places for the role of analyst and designer

Learning objectives (continued)

On completion of this week you should aim to be able to (cont.):
Explain how a systems development methodology provides guidelines for completing system development tasks, techniques and tools to help execute those tasks, together with models of system development processes and products. Explain the foundations of the main adaptive development methodologies

www.it.monash.edu

www.it.monash.edu

Learning objectives (continued)

On completion of this week you should aim to be able to (cont.):
List and describe the features of agile modelling Explain the main features of the ICONIX methodology

The nature of systems development

Information systems
Crucial to success of modern business organizations Constantly being developed to make business more competitive Impact productivity and profits

Each week, your reading of the texts is vital to achieving the learning objectives.

Keys to successful systems development

Thorough systems analysis and design Understanding what business requires

www.it.monash.edu

www.it.monash.edu

Key concepts
Systems analysis
What system should do

The analyst as a business problem solver

Has computer technology knowledge and programming expertise Understands business problems Uses logical methods for solving problems Has fundamental curiosity Wants to make things better Is more of a business problem solver than technical programmer

Systems design
How components of information system should be physically implemented

Systems analyst
Uses analysis and design techniques to solve business problems with information technology

www.it.monash.edu

www.it.monash.edu

Required skills of the systems analyst

An analyst should have fundamental technology knowledge of:
Computers / peripheral devices (hardware) Communication networks and connectivity Database and database management systems (DBMS) Programming languages (for example: VB.NET or Java) Operating systems and utilities

Technical knowledge and skills

Analyst uses tools: Software productivity packages (MS Office) Integrated development environments (IDEs) for programming languages CASE tools / coding, testing, and documentation support packages > For example: Rational Rose and Sybase PowerDesigner, Visual Paradigm Analyst understands SDLC phase techniques: Project planning Systems analysis, systems design Construction, implementation, systems support

www.it.monash.edu

www.it.monash.edu

Business knowledge and skills

Analyst must understand:
Business functions performed by organization Organizational structure Organization management techniques Functional work processes

People knowledge and skills

Systems analysts need to understand how people:
Think, learn, react to change, communicate, work (in a variety of jobs and levels)

Interpersonal and communication skills are crucial to:

Obtaining information, motivating people, getting cooperation, understanding the complexity and workings of an organization in order to provide necessary support

Many systems analysts will have chosen business electives in their University course

www.it.monash.edu

www.it.monash.edu

Typical job titles and places of employment

Job titles of systems analyst vary greatly, but entail same thing Places of employment vary from small businesses to large corporations Analysts can be internal employees or outside consultants Analysts can be developing solutions for internal business managers or for external clients and customers

Key principles and practices used by systems analysts

Abstraction
Process of extracting core principles from a set of facts or statement Example: Metamodels describe the characteristics of another model

Models and modeling

An abstraction of something in the real world, representing a particular set of properties

www.it.monash.edu

www.it.monash.edu

Key principles and practices (continued)

Standards, templates and patterns
Standard solutions to a given problem or templates that can be applied to a problem

Systems development life cycle (SDLC)

Systems development project Planned undertaking with fixed beginning and end Produces desired result or product Can be a large job of thousands of hours of effort or a small one month project Successful development project: Provides a detailed plan to follow Organized, methodical sequence of tasks and activities Produces reliable, robust, and efficient system

Reuse
Building standard solutions and components that can be used over and over again

Methodologies
Include the rules, guidelines, and techniquesthat define how systems are built

www.it.monash.edu

www.it.monash.edu

Phases of the systems development lifecycle (SDLC)

Project planning: initiate, ensure feasibility, plan schedule, obtain approval for project Analysis: understand business needs and processing requirements Design: define solution system based on requirements and analysis decisions Implementation: construction, testing, user training, and installation of new system Support: keep system running and improve

SDLC and problem-solving

Similar to problem-solving approach
Organization recognizes problem (Project Planning) Project team investigates, understands problem and solution requirements (Analysis) Solution is specified in detail (Design) System that solves problem built and installed (Implementation) System used, maintained, and enhanced to continue to provide intended benefits (Support)

www.it.monash.edu

www.it.monash.edu

Scheduling project phases

Waterfall approach each phase falls into next phase
Freeze planning specifications before analysis Freeze analysis specifications before design Once go over the waterfall for each phase, do not go back

Scheduling project phases (continued)

Iteration - Work activities are repeated
Each iteration refines previous result Approach assumes no one gets it right the first time There are a series of mini projects for each iteration

Overlapping (or concurrent) phases

Waterfall is not realistic, we are not perfect Overlaps can be more efficient than waterfall

Example: Outline, rough draft, edited result Example: Blueprint, frame, completed house

www.it.monash.edu

www.it.monash.edu

The waterfall approach to the SDLC

Overlap of systems development activities

www.it.monash.edu

www.it.monash.edu

Iterations across life cycle phases

Methodologies and Models

Methodologies
Comprehensive guidelines to follow for completing every SDLC activity Collection of models, tools, and techniques

Models
Representation of an important aspect of real world, but not same as real thing Abstraction used to separate out aspect Diagrams and charts Project planning and budgeting aids

www.it.monash.edu

www.it.monash.edu

Some models used in system development

Some models of system components Flowchart Data flow diagram (DFD) Entity-relationship diagram (ERD) Structure chart Use case diagram Class diagram Sequence diagram Some models used to manage the development process PERT chart Gantt chart Organizational hierarchy chart Financial analysis models NPV, ROI

Tools and techniques

Tools
Software support that helps create models or other required project components Range from simple drawing programs to complex CASE tools

Techniques
Collection of guidelines that help analyst complete system development activity or task Can be step-by-step instructions or just general advice

www.it.monash.edu

www.it.monash.edu

Some tools used in system development

Project management application Drawing/graphics application Word processor/text editor Computer-aided software engineering tools (CASE) Integrated development environment (IDE) Database management application Reverse engineering tool Code generator tool

CASE tools
Computer-Aided System Engineering (CASE)
Automated tools to improve the speed and quality of system development work Contains database of information about system called repository

Upper CASE - support for analysis and design Lower CASE - support for implementation ICASE - integrated CASE tools Examples include CAs ERWin, IBMs Rational and Visual Paradigm for UML

www.it.monash.edu

www.it.monash.edu

Some techniques used in system development

Strategic planning techniques Project management techniques Data-modelling techniques Relational database design techniques Structured analysis techniques Structured design techniques Structured programming techniques Software testing techniques Object-oriented analysis and design techniques

SDLC variations
Many variations of SDLC in practice
No matter which one, tasks are similar

Based on variation of names for phases

SDLC compared to IE compared to UP

Based on emphasis on people

User-centered design, participatory design

Based on speed of development

Rapid application development (RAD) Prototyping

www.it.monash.edu

www.it.monash.edu

Life cycles with different names for phases

Adaptive approaches to development

Less emphasis on up-front analysis, design, and documentation More focus on incremental development More user involvement in project teams Reduced detailed planning Used for near-term work phases only Tightly control schedules by fitting work into discrete time boxes More use of small work teams that are self-organizing

www.it.monash.edu

www.it.monash.edu

Agile development philosophy and modelling

Agile Development Principles
A philosophy and set of guidelines for developing software in an unknown, rapidly changing environment
>Requires agility being able to change direction rapidly, even in the middle of a project

Agile development philosophy and values

Responding to change over following a plan
An agile project is chaordic both chaotic and ordered

Agile Modelling Principles

A philosophy about how to build models, some of which are formal and detailed and others are sketchy and minimal

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation

www.it.monash.edu

www.it.monash.edu

Agile modeling (continued)

Simplicity:
Use simple content Depict models simply Use simplest modeling tools

Agile modelling principles

AM is about doing the right kind of modeling at the right level of detail for the right purposes
Use models as a means to an end instead of building models as end deliverables Does not dictate which models to build or how formal to make those models Has basic principles to express the attitude that developers should have as they develop software

Validation
Consider testability Prove model is right with code

www.it.monash.edu

www.it.monash.edu

Agile modelling principles

Develop software as your primary goal Enable the next effort as your secondary goal Minimize your modelling activity few and simple Embrace change, and change incrementally Model with a purpose Build multiple models Build high quality models and get feedback rapidly Focus on content rather than representation Learn from each other with open communication Know your models and how to use them Adapt to specific project needs

Agile modelling practices

Iterative and incremental modelling Teamwork Simplicity Validation Documentation Motivation

www.it.monash.edu

www.it.monash.edu

Adaptive methodologies using Agile modelling

Extreme programming (XP) Scrum methodology UP methodology ICONIX

Extreme programming (XP)

Lightweight, development approach to keep process simple and efficient Describes system support needed and required system functionality through informal user stories Users describe acceptance tests to demonstrate defined outcomes Relies on continuous testing and integration, heavy user involvement, programming done by small teams

www.it.monash.edu

www.it.monash.edu

Scrum
A quick, adaptive, and self-organizing development methodology
Named after rugbys system for getting an out-of-play ball into play Responds to a current situation as rapidly and positively as possible Empirical process control approach to developing software

Scrum philosophy
Responsive to a highly changing, dynamic environment Focuses primarily on the team level
Team exerts total control over its own organization and work processes

Uses a product backlog as the basic control mechanism

Prioritized list of user requirements used to choose work to be done during a Scrum project

www.it.monash.edu

www.it.monash.edu

Scrum organization
Product owner The client stakeholder for whom a system is being built Maintains the product backlog list Scrum master Person in charge of a Scrum project Scrum team or teams Small group of developers Set their own goals and distribute work among themselves

Scrum practices
Sprint The basic work process in Scrum A time-controlled mini-project Firm 30-day time box with a specific goal or deliverable Parts of a sprint Begins with a one-day planning session A short daily Scrum meeting to report progress Ends with a final half-day review

www.it.monash.edu

www.it.monash.edu

The Unified Process (UP)

Object-oriented development approach Offered by IBM / Rational
Booch, Rumbaugh, Jacobson

The Unified Process (UP) (continued)

Reinforces six best practices
Develop iteratively Define and manage system requirements Use component architectures Create visual models Verify quality Control changes

Unified Modeling Language (UML) used primarily for modeling UML can be used with any OO methodology UP defines 4 life cycle phases
Inception, elaboration, construction, transition

www.it.monash.edu

www.it.monash.edu

ICONIX
Agile development method that uses UML
Our focus in this unit Described by the RS text

ICONIX Overview

Focus on early GUI and domain modelling. UML use cases organise detailed design

www.it.monash.edu

www.it.monash.edu

Project management and adaptive methodologies

Project time management Smaller scope and focused on each iteration Realistic work schedules Project scope management Users and clients are responsible for the scope Scope control consists of controlling the number of iterations Project cost management More difficult to predict because of unknowns

Todays summary
Information systems development is much more than writing programs Systems analyst solves business problems using information systems technology Problem solving means looking into business problem in great detail, completely understanding problem, and choosing best solution

www.it.monash.edu

www.it.monash.edu

Summary (continued)
Systems analyst has broad knowledge and variety of skills, including technical, business, and people Many different paths and approaches to the SDLC Waterfall, overlap, iterative Analysis focuses on what a system has to do Design focuses on how a system is going to do it A methodology is a set of guidelines to follow for completing every SDLC activity

Summary (Cont.)
Adaptive development methodologies Unified Process (UP)! Agile Modelling and Agile Development Extreme Programming (XP)! >Tests are written first; programmers work in pairs Scrum >Defines a specific goal that can be completed within four weeks ICONIX >Early GUI and domain modelling >Development guided by UML use cases

www.it.monash.edu

To do before next week

Get a copy of the text book SJB.
Read SJB chapter 1, 2 and sections of 17 (5th edition) or 14 (6th edition) on XP, Scrum and Agile modeling

Download a copy of the text book RS

Read RS chapter 1

Verify your understanding of the key terms at the end of SJB chapter 1 Try the week 1 quiz on the Moodle web site