Week 1

Friday, 5 August 2011 10:06 AM

Week 1
Week 9 fake lab Week 10 proper lab Dr. Ovidiu Noran O.Noran@Griffith.edu.au Email for office hours

Assessment Task Quiz 5 In-class Quizzes Mid Semester Exam During Class Mid-semester examination Laboratory Assessed Lab Exam during Exam Period (Central) Final Examination

Due Date

Weightin Learning g Objectives 1, 2, 3 1, 2, 3, 4, 6

Lectures weeks 3, 5, 8, 10, 12 25% (approx) Week 6 lecture time 20%

Week 10 Examination Period

25% 30%

3, 4, 6 1, 2, 3, 6

Look at the essential resources to get the ms project and ms visio Chapter 1 And Chapter 2 System a collection of interrelated components functioning together to achieve an outcome. Information system same as before, but with the goal of passing information Subsystem: part of a larger system Functional decomposition dividing a system into smaller subsystems and component

System Analysis and Design Page 1

Database is the most important tool 2-4pm lecture is actually a workshop Analysts should have a fundamental technology knowledge Analysts use tools Analysts understands SDLC techniques Analysts must understand the business and the organization System analysts must be an effective communicator Must also be able to preform various roles such as negotiator, teacher, mentor, collaborator, and manager Analyst has access to confidential information System analyst related careers are things like Consultant Analyst Developer Architect Analysts role in strategic planning are into things like Special projects affecting executives, Strategic Planning process Information systems strategic planning Application is how the systems interact Technology is the infrastructure Summary A system 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 Information system development is much more than writing programs System a collection of interrelated components functioning together to achieve an outcome. Information system outcome solution to a business problem Information systems, subsystems and components interact with and include hardware, software, inputs, outputs, data, people, and procedures
System Analysis and Design Page 2

inputs, outputs, data, people, and procedures System analyst has a broad knowledge and variety of skills, including technical business and people Integrity and ethical behaviour are crucial to success for the analyst Systems analyst encounters a variety of rapidly changing technologies Systems analyst works on strategic plans and then system development projects
Analyst's Approach to problem solving Research and understand the problem Verify benefits of solving problem outweigh the costs Define the requirements for solving the problem Develop a set of possible solutions(alternatives) Decide which is best and recommended Define the details of the chosen solution Implement the solution Monitor to ensure the desired results

System Analysis and Design Page 3

Week 2
Friday, 5 August 2011 10:07 AM

Gather information to learn problem domain Define system requirements Build prototypes for discovery of requirements Prioritize requirements Generate and Evaluate alternatives Review recommendation with management Design activities Design and integrate the network Design the application architecture Design the user interfaces Design the system interfaces Design and integrate the database Prototype for design details Design and integrate system controls Implementation activities Construct software components Verify and test Convert data Train users and document the system Install the system Support Activates Maintain system with things like Small patches, repairs, and updates

Enhance system with small upgrades or enhancements to expand system capabilities and larger enhancements that may require separate development projects
Support users like help desk or support team Methodologies are a comprehensive guideline to follow for completing every SDLC activity, also a collection of models, tools and techniques.

System Analysis and Design Page 4

Models are representations of an important aspect of the real world, but not the same as the real thing. Abstraction is used to separate out the aspects. Can be Diagrams and charts, can involve Project planning and budgeting aids.

Tools like software support that helps create models or other required project components, ranging from simple drawing programs to complex case tools to project management software

Techniques are a collection of guidelines that help analysts complete a system development activity or task. It can be a step by step instruction or just general advice

System Analysis and Design Page 5

There are two approaches to system development The traditional approach, also called structured system development. Structured analysis and design techniques Includes information engineering Structured programming: Improves computer program quality. Allows other programmers to easily read and modify the code. Each module hase one beginning and one ending. There are 3 programming constructs (sequence, decision, repetition.) Then there is the object oriented approach: Also called OOA, OOD, and OOP. View information system as collection of interacting objects that work together to accomplish tasks.

Top down Programming divides complex programs into hierarchy of modules. The module at top controls execution by calling the lower level modules. The modular programming is similar to top down programming. One program calls other programs to work together as a single system. Structured design: Techniques developed to provide design guidelines like what it is and what It accomplishes, and how it is organized. Modules are shown with structure charts Main principles of program modules are: Loosely coupled: independent modules Highly cohesive: one clear task
Structured Analysis Define what the system needs to do What the data system needs to store and use Inputs and outputs How functions work together Data flow diagrams and entity relationship diagrams show results of structured analysis Object orientated approach Views IS as collection of interaction objects. Objects are things that can respond to messages There are nothing but objects Objet oriented analysis: Define types of objects users deal with Shows use cases are required. Object oriented design Defines object types needed to communicate with people and devices in system Shows how objects interact Refins each type of object for implementation SDLC Variations Many variations of SDLC in practice
System Analysis and Design Page 6

Many variations of SDLC in practice Some increase emphasis on people Some increase speed of development Adaptive approaches The unified Process Extreme Programming Scrum Object oriented development approach Used primarily for modeling Can be used with any OO methodology Up defines 3 life cycle phases Reinforces six best practices: Develop iteratively Define and manage system requirements Use component architectures Create visual models Verify quality Control changes Extream proramming Lightweight development approach to keep process simple and efficient. Scrum Highly adaptive for project needs Summary System development projects are organized around the systems development life cycle(SDLC) Some projects use a predictive approach to the SDLC and others use a more adaptive approach to SDLC SDLC phases include project planning analysis, design, implementation, and support. In practice, phases overlap and projects contain many iterations of analysis, design, and implementation. Models, techniques, and tools make up a system development methodology System development methodology provides guidelines to complete every activity in the SDLC System development methodologies are based on traditional approach or object-oriented approach Current trends include: Extreme programming(XP), unified process(UP), and scrum Visual modelling tools are designed to help analysts complete system development tasks. Analyst as a project Manager Project requires careful planning, control, and execution. Reasons for project failure Incomplete or changing requirements Limited user involvement Lack of executive support Lack of technical support Poor project planning Unclear objectives
System Analysis and Design Page 7

Unclear objectives Lack of required resources Reasons for success Clear system requirement definitions Substantial user involvement Support from upper management Thorough and detailed project plans Realistic work schedules and milestones Role of the project manager Project management (duh) - manages the project to ensure everything happens Success or failure of project depends on the skills of the project manager Responsibilities are both internal and external Internal responsibilities Identify project tasks and build a work breakdown structure. Develop the project schedule Recruit and train team members Assign team members to task Coordinate activities of team members and their subteams Assessing the project risks Monitor and control project deliverables and milestones Verify the quality of project deliverables External responsibilities like reporting the project's status and progress, establishing good working relationships Work directly with the client Identify resources and obtain them Project management Tasks Planning the project Executing, control and closeout management Predictive SDLC and adaptive

System Analysis and Design Page 8

Level of Formality High formal projects and less formal projects Project management body of knowledge Scope management Time management Cost management Quality management Human resource management Communications management Risk management Procurement management Integration management Project initiation and project planning Driving forces to start project Project initiation comes from long term IS plan Department and process managers Response to outside forces

Key questions for project plannning

Defining the problem Review the business needs Identify expected system capabilites Create system scope document Build proof of concept prototype Create context diagram Producing the project schedule Develop work breakdown structure(WBS) Build/represent a schedule using Gantt charts and PERT (network)charts
System Analysis and Design Page 9

Build/represent a schedule using Gantt charts and PERT (network)charts Develop resource requirements and staffing plan Representing the project schedule Identify each activity Determine time estimates and calculate the expected completion of time Determine the sequence of activities and precedence relationships among all activities Determine the critical path Plot the project schedule

PERT(Program evaluation review technique) a technique that uses optimistic pessimistic and realistic time estimates to calculate the expected time for a particular task Formula for estimated time: ET = (o + 4r + p)/6 ET= expected time O = optimistic completion time R = realistic completion time P = pessimistic completion time Critical path Earliest possible completion time for total expected project time summing estimated activity times for the longest path Latest possible completion time, subtracting estimated activity time in the path following gives slack time Slack time - the amount of time that an activity can be delayed with problems Free slack: amount of time a task can be delayed without delaying the early start of the next task. Total slack: amount of time the task can be delayed without problems

System Analysis and Design Page 10

Gantt chart example

Identifying Risks and confirming project feasibility

Organizational and Cultural Feasibility Each company has own culture New system must fit into culture Evaluate related issues for potential risks Technological feasibility Does the system strech state of the art technology Does in house expertise presently exist for development Does an outside vendor need to be involved Get the Microsoft Project from Uni

System Analysis and Design Page 11

Tutorial, Week 2
Friday, 5 August 2011 2:08 PM

Automation boundary: the boundary between the scale of human work and machine work What does a Human Resource Management system support? Employees, clients, customers, etc Description of the integrated IS of business is? Best approach when exact requirements of system/users not know? Adaptive approach The approach that completes a system in one or more iterations is called adaptive development Structured programming constructs? Sequences, decisions, interaction. What kind of skills should an Analyst have? Apart from tech skills, should also have the business skills, and people skills Main components of a strategic plan? Can the two main system development approaches be mixed? Example? No problem mixing object orientated and traditional, but linking them is hard Name one best practice promoted by the unified process: work interactively. Also check quality Name a critical factor in the acceptance of a system nowadays? The user interface, graphic How many critical paths in a project? Any number, depending on the project

System Analysis and Design Page 12

Week 3
Friday, 12 August 2011 9:56 AM

Overview Analysis phase of SDLC skills needed Finding facts when investigating the system requirements Analysts should learn the details of business processes and the daily operations. Analysts should become as knowledgeable as business domain users to build credibility Analyst brings fresh perspective to problem. Modelling of business processes based on system requirements. So, in a short up Able to: Gather information, define system requirements(functional and nonfunctional), Prioritize requirements, prototype for feasibility and discovery, generate and evaluate alternatives, review recommendations with management. The activities of the Analysis phase

System Requirements - specifications that define the new system Functional requirements: Activities system must perform (use cases) Based on procedures and business functions Documented in analysis models Nonfunctional requirements Technical requirement - hardware and software Performance requirement - workload measures Usability requirement - user interface, workflow Reliability requirement - outages, error detection Security requirement - access and protection Models and Modelling Models are used to describe information system requirements Complex systems use more then one type of model
System Analysis and Design Page 13

Complex systems use more then one type of model Models will represent an aspect of the system being built The model creation process helps the analyst clarify and refine the design. Also assists with communication with the system users. Reasons for Modelling

What you see, is the most important part of a model Different types of Models are used in information system development Mathematical - formulas that describe technical aspects of the system Descriptive - narrative memos, reports, or lists that describe aspects of the system Graphical - diagrams and schematic representations of some aspect of the system. Define system requirements use logical models to provide detail without regard to specific technology. Design models use physical models, which provide technical details, and extend logical models Models created during Analysis

System Analysis and Design Page 14

Models created during Analysis

Stakeholders are people with interest in successful system implementation Three groups of stakeholders Users (who use the systems) Clients (pay for and own system) Technical staff (ensure system operation) Every type of stakeholder is identified by analyst.

Horizonal user roles - information flow across departments Vertical user roles - information needs of clerical staff, middle management, and senior executives Business users perform day to day operations Information users need current information Management users need summary information Executive users need strategic information External users may have access to system Techniques for information gathering Original structured approach Create model of existing system Derive requirements from existing system model
System Analysis and Design Page 15

Derive requirements from existing system model Current approach Identify logical requirements for new system Balance the review of current business functions with new system requirements.

Fact finding methods Reviewing existing reports, forms, and procedure descriptions Identify business rules, discrepancies, and redundancies Be cautious of outdated materials Obtain preliminary understanding of processes Use as guidelines/visual cues to guide interviews Interview and discuses processes with users Effective way to understand business functions and rules Time consuming and resource expensive May requrie multiple sessions Can meet with Individuals or groups of users Observe and document business processes Varies from office walkthroughs to performing actual tasks Not necessary to observe all processes at same level of detail May make users nervous, so use common sense Can document workflows with UML activity diagrams Build prototypes Prototype -Preliminary working model of a larger, more complex system component Discovery, design, evolving prototypes Prototype should be Operative Working model to provide look and feel Focused to accomplish single objective Quick Built and modified rapidly with CASE tools Distribute and collect questionnaires Limited and specific information from a large number of stakeholders
System Analysis and Design Page 16

Limited and specific information from a large number of stakeholders Preliminary insight into business Not well suited for gathering detailed information Closed-ended questions direct person answering question Open-ended questions encourage discussion and elaboration Conduct joint application design (JAD) sessions Expedites investigation of system requirements Seeks to compress fact-finding, modeling, policy formation, and verification activities into shorter time frame Critical factor is to have all important stakeholders present Research vendor solutions. Many problems have been solved by other companies Positive contributions of vendor solutions Frequently provide new ideas May be state of the art Cheaper and less risky Danger May purchase solution before understanding problem User Goals, Events, and use Cases Use Case -- An activity the system preforms in response to a user request. Techniques for identifying use cases EBP - a task preformed by one user, in one place in response to a business event, that adds measurable business value, and leaves system and data in consistent state. CRUD analysis techniques (create, read, update, delete) Event decomposition technique EDT - Event decomposition Technique Event - an occurrence at a specific time and place and which needs to be remembered. Business events trigger elementary business processes EBPs are at correct level of analysis for use cases Identify business events to decompose system into activities/use cases Types of Events External, outside system Initiated by external agent or actor Temporal Occur as result of reaching a point in time Based on system deadlines State, Something inside system triggers processing need

System Analysis and Design Page 17

Quiz stuffs
Friday, 12 August 2011 10:07 AM

Questio n1

0.25 out of 0.25 points A collection of interrelated components that collect, process, store, and provide as output the information needed to complete business tasks constitutes ... Selected Answer: Correct Answer: an information system an information system

Questio n2

0 out of 0.25 points Which of the following is the analysts approach to problem solving? Correct Answer:

Verify that the benefits of solving the problem outweigh the costs, then define the requirements for solving the problem.

Questio n3

0 out of 0.25 points A technique that seeks to alter the nature of the work done in a business function, with the objective of radically improving performance, is called .... Correct Answer: business process re-engineering

Question 4

0.25 out of 0.25 points A system that is part of a larger system is called ... Selected Answer: Correct Answer:

a subsystem a subsystem

Question 5

0 out of 0.25 points A process in which executives try to answer key questions about the company is called ... Correct Answer: strategic planning

Question 6

0 out of 0.25 points Which of the following is an example of a technique used to complete specific system development activities? Correct Answer: project planning

Questio System Analysis and Design Page 18

0 out of 0.25 points

n7
After investing resources in thoroughly understanding the business problem, the analyst decides that the costs of solving the problem will likely outweigh the benefits. Thus the analyst should ... Correct Answer: suggest that the project be discontinued

Questio n8

0 out of 0.25 points Changes in software development, technology, and business practices have created many new career opportunities for analysts, including Correct Answer: all of the above

Questi on 9

0.25 out of 0.25 points Rocky Mountain Outfitters would like to further distribute business applications across multiple locations and computer systems, reserving the data center for Web server, database, and telecommunications functions. This is an example of... Selected Answer: Correct Answer: technology architecture planning technology architecture planning

Question 10

0 out of 0.25 points A process in which an organization commits to using an integrated set of software packages for key information systems is called ... Correct Answer: enterprise resource planning (ERP)

Question 11

0 out of 0.25 points

Skills in technical areas such as programming and network design are called.... Correct Answer:

hard skills

Question 12

0.25 out of 0.25 points A business professional who uses analysis and design techniques to solve business problems using information technology is called... Selected Answer: Correct Answer: systems analyst systems analyst

Question 13

0 out of 0.25 points The process of understanding and specifying in detail what the information system should accomplish is called systems ... Correct Answer: analysis

System Analysis and Design Page 19

Question 14

0.25 out of 0.25 points Specifying in detail how the many components of the information system should be physically implemented constitutes systems ... Selected Answer: Correct Answer: design design

Question 15

0 out of 0.25 points The division of a system into processes or subsystems is called ... Correct Answer:

functional decomposition

Question 16

0 out of 0.25 points The most important role of a systems analyst in business is ... Correct Answer:

problem solving

Question 17

0 out of 0.25 points Two systems that are externally oriented, i.e. they focus on entities outside of the organization are ... Correct Answer: customer relationship and supply chain management systems

Question 18

0.25 out of 0.25 points The system that is used to administer the people within an organisation is the .... Selected Answer: Correct Answer:

human resource management system human resource management system

Question 19

0.25 out of 0.25 points The process of understanding and specifying in detail what the information system should accomplish is referred to as .... Selected Answer: Correct Answer: systems analysis

systems analysis

Question 20

0 out of 0.25 points A description of the integrated information systems needed by the organization to carry out its business functions is called .... Correct Answer: application architecture plan

System Analysis and Design Page 20

System Analysis and Design Page 21

Tutorial, week 3
Friday, 12 August 2011 11:09 AM

What is a critical component for the user acceptance of a system: the Gooie part What is the most important/critical component of a system modelling and design tool? The central repository What is the main task of a help desk? Customer support What kind of human resources training is required there? People skills What is the critical path of a project? The path that contains the tasks that take the longest time to complete (how much time it'll take for the project to be done Can there be more such paths? Yes What is the slack time of an activity? The extra time to finish the task What is PERT? Program Evaluation Review Technique (optimistic, pessimistic, realistic/6 = estimated time) What is a model? Representation of reality (simplified) What is a methodology? Methods, models and tools What is SDLC and what could spiral SDLC be? System Development Life Cycle, The phases of the system to operate, etc. Spiral: Method where you do things again and again (repetatiiiiiiiiive bitches) aka repetitive life cycle(they keep going back through the same iterations, to keep refining the system)

What SDLC approach is used when the exact requirements of a system are not known/can change significantly? Adaptive
What are the basic structured programming constructs? Sequence, cycle, decision. What is the object oriented design approach? Approaches everything as an object, and shows how the object interacts with the design Strategic IS plan directs IS developments project priorities Project charter describes key participants Defining the Problem Review business needs Use strategic plan documents Consult key users Develop list of expected business benefits Identify expected system capabilities Define scope in terms of requirements Create system scope document Build proof of concept prototype Create context diagram Break even point: when benefit starts to outweigh the cost Tangible benefit: A benefit you can touch (monies)
System Analysis and Design Page 22

Tangible benefit: A benefit you can touch (monies) The Program Evaluation Review Technique: ET=(optimistic+4*realistic+pessimistic) / 6 Eg. A: o=3, r=7, p=11 ET= (3+4*7+11) / 6 = 7 What about: o=3, r=11, p=7 ? o=11, r=7, p=3 ? (i.e. be careful about irrational propositions) Join application Design facility

Research vendor solutions Many problems have been solved by other companies Positive contributions of vendor solutions Frequently provide new ideas May be state of the art Cheaper and less risky Danger May purchase solution before understanding problem Useful Techniques in Vendor Research Technical specifications from vendor Demo or trial system References of existing clients On-site visits Printout of screens and reports alidating the Requirements Make sure gathered information is correct Structured walkthrough Effective means of implementing quality control early in project Verify and validate system requirements Review of findings from investigation and of models based on findings Project manager responsible for system quality Systems analyst, project manager are partners Summary Analysis phase activities Gather information Define system requirements Prioritize requirements Prototype for feasibility and discovery Generate and evaluate alternatives
System Analysis and Design Page 23

Generate and evaluate alternatives Review recommendations with management BPRand ZachmanFrameworkcan help with the analysis phase activities Summary (continued) Gathering system requirements Functional and nonfunctional Work with various stakeholders (users, clients, technical staff) What kind of information do I need? What are the business processes and operations? How are the business processes performed? What are the information requirements? Summary (continued) Primary information-gathering techniques Review existing reports, forms, and procedure descriptions Conduct interviews and discussions with users Observe and document business processes Build prototype working models Distribute and collect questionnaires Conduct JAD sessions Research vendor solutions

System Analysis and Design Page 24

Week 4 quiz stuff

Friday, 19 August 2011 10:04 AM

What are the functional system requirements? What the system has to do How about non functional system requirements? Tech, performance, user requirements What are some types of models used in system analysis and design Mathematical, descriptive, and graphical Difference between logical and physical models Logical involves describing, planning, etc, while physical is actually working on it What are typical stakeholders types? Users, suppliers, supporters What is a workflow? Steps you have to undertake What is a common document for this: activity model What is a swimlane in an activity model? Keepings yourself to your lane of activity What are synchronisation bars and when are they used. Used to synchronise activities What are use cases? Things that the system does, in response to user action How are use cases discovered? Asking the user questions What does C.R.U.D. Create, Read, Update, and delete

What is an actor, how about a scenario Actor - something or someone who uses the system Scenario - particular set of steps

System Analysis and Design Page 25

Week 4
Friday, 19 August 2011 11:05 AM

Summary Analysis phase - defines system requirements Models created to further learning process, reduce complexity, communicate with team members, and document requirements Key early step in modeling is to identify and list Use cases (activities) are identified from user goals and business events that trigger elementary business processes Business events are memorable, can be described, and occur at a specific time and place External events, temporal events, and state events Event table records event, trigger, source, use case, response, and destination A catalogof information about each use case Thingsare what user deals with and system remembers, such as customer placing an order Traditional approach uses entity-relationship diagrams (ERD) for data entities, attributes of data entities, and relationships between entities Object-oriented approach uses UML class diagrams for classes, attributes, methods of class, and associations among classes Domain model class diagram Multiplicity of associations

System Analysis and Design Page 26

Multiplicity of associations

More complex class concepts Generalization/specialization hierarchies General superclasses to specialized subclasses Inheritance allows subclasses to share characteristics of their superclasses Traditional Approach to system Requirements
Data Flow Diagrams Raphical system model that shows all main requirements for an IS in one diagram Inputs/outputs Processes Data storage Easy to read and understand with minimal training Data flow diagram key

Documentation of DFD Components Lowest level processes described in necessary detail Data flow content need to be described Data stores need to be described in terms of data elements Each data element needs to be described Various options for process definition exist
System Analysis and Design Page 27

Various options for process definition exist Look up item availability from the RMO

DFD integrated Event Table and ERD

DFD and Levels of Abstraction Data flow diagrams (DFDs) are decomposed into additional diagrams to provide multiple levels of detail Higher-level diagrams provide general views of system Lower-level diagrams provide detailed views of system Differing views are called levels of abstraction

System Analysis and Design Page 28

Context Diagrams DFD that summarizes all processing activity for the system or subsystem Highest level (most abstract) view of the system Shows system boundaries System scope is represented by a single process, external agents, and all data flows into and out of the system DFD Fragments Created for each use case in the event table Represent system response to one event within a single process symbol Self-contained models Focus attention on single part of system Show only data stores required in the use case

Event-Partitioned System Model DFD to model system requirements using single process for each use case/activity in system or subsystem Combines all DFD fragments together to show decomposition of the context-level diagram Sometimes called diagram 0 Used primarily as a presentation tool Decomposed into more detailed DFD fragments
System Analysis and Design Page 29

Decomposed into more detailed DFD fragments

Decomposing DFD Fragments Most DFD fragments can be further described using structured English Sometimes DFD fragments need to be diagrammed in more detail Decomposed into subprocessesin a detailed DFD DFD numbering scheme Hierarchical decomposition DFD Fragment 2 is decomposed into Diagram 2 Diagram 2 has processes 2.1, 2.2, 2.3, 2.4

Physical and Logical DFDs Logical Model

System Analysis and Design Page 30

Logical Model Assumes implementation in perfect technology Doesn't tell how system is implemented Physical model Describes assumptions about implementation technology Developed in last stages of analysis or in early design

Evaluating DFD Quality Readable Internal consitent and balanced Accurately represents system requirements Reduces information overload - rule of 7 +/-2 Single dfd should not have more than 7 +/- 2 processes No more then 7+/-2 data flows should enter or leave process or data store in a single dfd Minimizes required number of interfaces Data flow consistency problems Differences in data flow content between a process and its process decomposition Data outflows without corresponding inflows Data inflows without corresponding outflows Results in unbalanced DFDs Consistency rules All data that flows into a process must Flow out of a process or be used to generate data that flows out of the process All data that flows out of a process must Have flowed into the process or have been generated from data that flowed into the process

System Analysis and Design Page 31

Week 4 tutorial
Friday, 19 August 2011 1:58 PM

Unnecessary Data input: Black hole

ensure you know data flow Process with Impossible Data Output: A miracle

Process with Unnecessary Data Input

System Analysis and Design Page 32

Process with impossible data output

Data flow diagramming rules

System Analysis and Design Page 33

System Analysis and Design Page 34

Common DFD Errors 3.1.2 Black Hole 3.1.1 Grey Hole 3.1.3 Miracle

Balancing DFDs Conservation Principle: conserve inputs and outputs to a process at the next level of decomposition Balancing: conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower lever, thus: Number of inputs to lower level DFD equals number of inputs to associated process of higher level DFD Number of outputs to lower level DFD equals number of outputs to associated process of higher level DFD Balancing DFD's examples

System Analysis and Design Page 35

Balancing DFD's examples

This is unbalanced because the process of the context Diagram has only one input, but the level 0 diagram has 2 inputs Data flow splitting is when a composite data flow at a higher level is split and different parts go to different processes in the lower level DFD The DFD remains balanced because the same data is involved, but splits into 2 parts

Rules for balancing DFD

System Analysis and Design Page 36

Structured English is a method of writing process specifications Combines structured programming techniques with narrative English Well suited for lengthy sequential processes or simply control logic and ill suited for complex decision logic and few sequential processing steps Example

Decision tables and trees can summarize complex decision logic better then structured English
System Analysis and Design Page 37

Decision tables and trees can summarize complex decision logic better then structured English Incorporate logic into the table or tree structure to make descriptions more readable Example table

Example tree

Data flow definitions Textual description of data flow's content and internal structure. Often coincide with Attributes of data entities included in ERD plus computed values. Algebraic notion describes data elements on data flow plus data structure. Example

Components of a traditional analysis model

Locations and Communication through networks Logical information needed during analysis Number of user locations
System Analysis and Design Page 38

Number of user locations Processing and data access requirements at various locations Volume and timing of processing and data access requests Needed to make initial design decisions such as Distribution of computer systems, application software, database components, network capacity Summary Data flow diagrams are used in combination with event table and entity relationship diagram to model system requirements DFDs model system as set of processes, data flows, external agents, and data stores DFDs easy to read - graphically represent key features of system using small set of symbols Many types of DFDs - context diagrams, DFD fragments, subsystem DFDs, event-partitioned DFDs, and detailed process DFDs. Each process, data flow, and data store requires detailed definition Analysts may define processes as structured English process specifications, decision tables, decision trees, or detail process DFDs Detailed process decomposition DFDs used when internal process complexity is great. Data flows are defined by component data elements and their internal structure

System Analysis and Design Page 39

Week 5
Friday, 26 August 2011 10:09 AM

The OO approach to system requirements Overview The objective of requirements definition is understanding - understanding the users' needs, the business processes, and the systems to support business processes. Understand and define requirements for a new system using object-orinted analysis models and techniques. Line between object-oriented analysis and object-oriented design is somewhat fuzzy. Iterative approach to development Models built in analysis are refined during design Object oriented modeling notation is Unified Modeling Language, which was accepted by Object Management Group as standard modeling techniques. The purpose of the Object Management Group Promote theory and practice of object-oriented technology for development of distributed systems Provide common architectural framework for OO Object oriented system requirements are specified and documented through process of building models, which starts with identification of use cases and problem domain classes. Business events trigger elementary business processes (EBP) that new system must address as use case. Use cases define functional requirements Use case model - a collection of models to capture system requirements Use case diagram - identify actors and their roles and how the actor roles utilize the system Systems sequence diagrams - define inputs and outputs and sequence of interactions between user and system for a use case Message - the communication between objectives within a use case Dormain model - desciribes the classes of objects and their states State machine diagrams - describes the classes of objects and their states The system activities - A use case/scenario view Use case analysis used to identify and define all business processes that system must support Use case - an activity a system carried out, usually in response to a user request. Actor Role played by user Outside automation boundary Use case diagram Graphical UML diagram that summarizes information about actors and use cases Simple diagram shows overview of functional requirements Can have multiple use case diagrams By subsystem By actor <<includes>>Relationship Documents situations in which one use case requires the the services of a common subroutine Another use case is developed for this common subroutine A common use case can be reused by multiple use cases Developing a use case diagram
System Analysis and Design Page 40

Developing a use case diagram Underlying conditions for describing use cases Based on automated system, eg users touch the system Assume perfect technology Iterate through those two steps Identify actors as roles List goals, eg use cases for each actor. A goal is a unit of work Finalize with CRUD analysis to ensure completeness Activity Diagrams Used document workflows of business process activities for each use case or scenario Can support any level of use case description; a supplement to use case descriptions Helpful in developing system sequence diagrams Identifying inputs and outputs - the system sequence diagram Interaction diagram - a communication diagram or a sequence diagram System sequence diagram (SSD) is type of interaction diagram Used to model input and output messaging requirements for a use case or scenario Shows sequence of interactions as messages during flow of activates Used to model input and output messaging requirements for a use case or scenario Shows sequence of interactions as messages during flow of activites System is shown as one object: a block box SSD notation Lifeline or object lifeline is a vertical line under object or actor to show passage of time for object Message is labeled on arrows to show messages sent to or received by actor or system SSD lifelines Vertical line under object or actor Shows passage of time If vertical line dashed Creation and destruction of things is not important for scenario Long narrow rectangles Activation lifelines emphasize that object is active only during part of the scenario SSD messaes Internal events identified by the flow of objects in a scenario Requests from one actor or object to another to do some action Invoke a particular method Developing a system sequence Diagram Begin with detailed description of use case from fully developed form or activity diagram Identify input messages Describe messages from external actor to system using message notations Identifies and adds any special condititions on input messages including iteration and true/false conditions, it also identifies and adds outputs of return messages Identifying object Behaviour The state machine diagram is used to model objects, states, and transitions, allowing it to model complex problem domain classes

State of an object is a condition that occurs during the objects life, when it satisfies some criterion, preforms some action, or waits for an event
Each state has unique name and is semipermanent condition or status Transition
System Analysis and Design Page 41

Transition Movement of an object from one state to another Terminology for State Machine Pseudostate - the starting point of a state machine indicated by a black dot Origin state - the original state of an object from which the transition occurs Destination state - the state to which an object moves after the completion of a transition Message event - the trigger for a transition, which causes the object to leave the origin state. Guard condition - a true/false test to see if a transition can fire Action expression - A description of an activates performed as part of a transition Rules for developing state machine diagram Review domain class diagram, select important ones, and list all state and exit conditions Begin building state machine diagram fragments for each class Sequence fragments in correct order and review for independent and concurrent paths Expand each transition with message event, guard-condition, and action expression. Review and test each state machine diagram Summary Object oriented approach has complete set of diagrams that define system requirements Requirements specified using following models Domain model class diagram(chapter 5) Use case diagrams(Chapter 7) Use case detailed models, either descriptive formats or activity diagrams(5 and 7) System sequence diagrams (7) State machine diagrams(chap 7)

System Analysis and Design Page 42

Quiz stuff
Friday, 26 August 2011 10:21 AM

A place on the project schedule that indicates a specific completion point is called a mile stone Each class of things in a hierarchy can have a more general class above it called a Superclass Each class of things in a hierarchy can have a specific classes below it called a subclass A use case postcondition is a set of statements that is true...when? Objectives that should be true after the project is over What is JAD, and what is it used for? Joint Application Design, to share ideas and brainstorm - deals with requirements What do you call a unique path in a use case? Scenario What is cardinality? Number of between objectives What is an associative class? A class associated to another class What is a miracle in traditional approach? Giving an output with no inputs What is a DFD and what is it used for? Data flow diagram What is a source in a dfd, how about a sink Source gives data, sink takes data What is DFD balancing

System Analysis and Design Page 43

Week 7
Friday, 9 September 2011 10:06 AM

12) A place where data is held for access by one or more processes is a data store 11) Processes with data elements created out of nothing is called a miracle 10) What is an actor in OO SAD? Something or someone using the system 9) What represents the [ and ] symbols in a system sequence diagrams? Guard condition 8) Why are names underlined in a system sequence diagram? Cus their objects 7) 6) How do we represent actors in a use case diagram? 5) What are the dashed vertical lines in a sequence diagram? time 4) What does a state transition diagram show? States of objects 3) What are horizontal bars used for in activity diagrams? syncbars 2) How many classes in a system sequence diagram? none 1) how is repetition shown in a system sequence diagram? Have arrows returning to their source Last three activities of analysis Prioritize system requirements Generate and evaluate alternatives Review recommendation with management Project management perspective Deciding on scope and level automation Scope determines which business functions will be included in the system The level of automation is how much computer support exists for functions included in scope. Scope creep Requests for addition of system functions after requirements have been defined and decisions have been made Users typically request more business functions then budget allows Levels of automation Low level Functions automated for simple computer record keeping Medium level Mid range point that combines features from low and high alternatives High level System automates most processing of business functions Selecting an implementation alternative Identifying criteria for selection Comparisons can be difficult Different proposed systems have strengths in different areas Three major areas to consider General requirements Technical requirements Function requirements Making the selection First rate each alternative with raw scores Weighted scores are then tabulated and compared to make a choice RMO decided on in-house development for most CSS development to keep expertise within RMO RMO wants to hire some new technical specialists RMO feasibility review showed no serious problems after specialists are added

System Analysis and Design Page 44

Contracting with vendors Generate request for proposal Formal document sent to vendors in-house development is not selected States requirements and solicits proposed solutions Considered a competition contract offer Bid on supplying hardware, software, and/or support services Benchmarking and choosing a vendor Observe in use or install trial version Benchmark - evaluate the system against a standard Visit another company using a particular system Develop a contract Fixed dollar - risk is on vendor Cost plus percentage - risk on purchaser Cost plus fixed fee - risk on both sides

Summary These activities are primarily project manager responsibilities with support from project team Focus of project changes from discovering requirements to developing solution system Prioritize requirements based on scope and level of automation Scope of new system determines functions it will support Level of automation is a measure of how automated the selected functions will be Application deployment environment Computer hardware, systems software, and networks in which new system will operate Determines constraints imposed on system development alternatives Analyst must define environment to match Application requirements Organizations strategic application plans Organizations technology architecture plans Determine what alternatives are possible for developing solution Implementation alternatives include Building system in-house Buying packaged or turnkey solution Contracting with developer to build system (outsource) Develop recommendations and present to management to make funding decisions

System Analysis and Design Page 45

Week 8
Friday, 16 September 2011 10:08 AM

Lecture 4 had a bit of review on traditional approach, and the flow chart key Structure approach to designing the application architecture Application software programs are designed in conjunction with database and user interfaces, and also has a hierarchy of modules Uses the top down approach, with DFD (data flow diagrams) with automation boundaries, system flowcharts, structure charts, and pseudocode. Structured design models

The Automation system boundaries It partitions data flow diagram processes into manual processes and automated systems. These processes can be inside or outside the boundary The data flows can be inside and outside of the boundary. The data flows that cross the boundary represent the inputs and outputs of the system Data flows that cross the boundaries between programs represent program to program communication. A DFD with automation system boundary

System Analysis and Design Page 46

The system flowchart is a representation of various computer programs, files, databases, and associated manual processes that make up complete system. These are often constructed during the analysis activity stage It describes graphically the organization of subsystems into automated, and manual components, and can show types of transaction processing system, like batch and real time. Common system flowchart symbols

The structure chart describes functions and subfunctions of each part of the system. And also shows relationships between modules of a computer, it's simple and direct organization. Structure chart symbols

System Analysis and Design Page 47

Structure chart symbols

Developing a structure chart Transaction analysis What needs to happen Uses system flow charts and even table inputs The upper level modules are developed first And identifies each transaction supported by the program Transform analysis How it happens Uses DFD fragments for inputs Computer program transforms inputs into outputs Charts have input, calculate, and output subtrees Steps to create a structure chart from DFD fragments Add other modules Get input data via user interface screens Read from and write to data storage Write output data or reports Add logic from structured English or decision tables Make final refinements to structure chart based on quality control concepts Create new order DFD Fragment

System Analysis and Design Page 48

Structure chart for the create new order program

Evaluating the quality of a structure chart Module coupling Which is a measure of how module is connected to other modules in program Module cohesion Measure of internal strength of module The more cohesive the module is, the less coupling it needs Example of module cohesion

System Analysis and Design Page 49

Example of module cohesion

The module algorithem design - pseudocode Which describes internal logic of software modules Three types of control statements used in structured programming Sequence - sequence of executable statements Decision - if then else logic Iteration - do until or do while Integrating structured application design with other design tasks The structure chart must be modified or enhanced to integrate design of user interface and database Structure charts and system flowcharts must correspond to planned network architecture Three layer design Three layer architecture is view layer, business logic layer, and data layer Employs multiple programs for user interface, business logic, and data access modules Modules in different layers communicate over real time links, using well defined protocols System flowchart showing three layer architecture for customer order

Summary For traditional structured approach to systems design, primary input is data flow diagram DFD is enhanced by adding system boundary
System Analysis and Design Page 50

DFD is enhanced by adding system boundary Designer describes processes within each DFD boundary using one or more structure charts Structure charts developed using Transaction analysis multiple transaction types Transform analysis single transaction from input to output Structure charts may be based on three-layer architecture Modules will be clearly identified by layer Structure chart may be decomposed if layers execute on multiple systems Structured design may also include System flowcharts to show data movement Module pseudocodeto describe internal logic of structure chart module

System Analysis and Design Page 51

Quiz
Friday, 16 September 2011 11:03 AM

What in as intranet: Private network (can have a wide area network) What is an extranet: Public network What is a client server architecture? (causes all sorts of problems, whatever it is) What are the 4 layers in a client server architecture? Presentation, logic, and storage Which layer contains the main processing preformed by the system? The logic/business Which layer is the most important for user acceptance of the system? Presentation How is the system represented in a system sequence diagram? As an object What are the dashed vertical lines in sequence diagrams: lifelines What are the symbols for a guard condition? [...] What are use cases? Describes the way users interact with the system What are DFD fragments? Fragments of use cases What is a level 0 DFD diagram? The class that everything runs into

System Analysis and Design Page 52

Week 11
Friday, 14 October 2011 10:03 AM

Design patterns: A standard solution template to a design requirement that facilitates the use of good design principles Use case controller pattern: Design requirement is to identify which problem domain class should receive input messages from the user interface for a use case. Artifact - a class invented by a system designer to handle a needed system function, such as a controller class. Use case controller Pattern

Use case realization with sequence Diagrams Realization of use case done through interaction diagram development Determine what objects collaborate by sending messages to each other to carry out use case Sequence diagrams and communication diagram represent result of design decisions. Designing with sequence diagrams Sequence diagrams used to explain object interactions and document design decisions Document inputs to and outputs from system for single use case or scenario. Capture interactions between system and external world as represented by actors Inputs are messages from actor to system Outputs are return messages shown data. Object responsibility Objects are responsible for system processing Responsibility's include knowing and doing Design means assigning responsibility to the appropriate classes based on design principles and using design patterns First cut sequence Diagram Start with elements from SSD
System Analysis and Design Page 53

Start with elements from SSD Replace :system object with use case controller Add other objects to be included in use case Determine other messages to be sent Guidelines for sequence diagram development for use case Take each input message and determine internal messages that result from that input Flesh out components for each message Assumptions about first cut sequence diagram Perfect technology assumptions Perfect memory assumption Perfect solution assumption Summary Systems design is driven by use cases, design class diagrams, and sequence diagrams Domain class diagrams are transformed into design class diagrams Sequence diagrams are extensions of system sequence diagrams(SSDs) System sequence Diagrams Capture method signatures Show navigation visibility Guidelines for sequence diagram development for use case Take each input message and determine internal messages that result from that input Flesh out components for each message

Same assumptions
Developing a multilayer design First cut sequence diagram - use case control plus classes in domain layer Add data access layer - design for data access classes for separate database interaction Add view layer - design for user interface classes Approaches to data Access layer Create data access class for each domain class Approach (a) - controller instantiates new customer aC; new instance asks DA class to populate its attributes reading from database Approach (b) - controller asks DA class to instantiate new customer aC; DA class reads database and passes values to customer constructor Designing the view layer Add GUI forms or web pages between actor and controller for each use case Some use cases require only one form; some require multiple forms and dialog boxes View layer design is focused on high level sequence of forms/pages - dialog Designing with communication diagrams Communication diagrams and sequence diagrams: Both are interaction diagrams Both capture the same information Process of designing is same for both Model used is designer's personal preference Sequence diagram - use case descriptions and dialogs follow sequence of steps Communication diagram - emphasizes coupling Updating the design class diagram Design class diagrams developed for each layer Sequence diagrams messages used to add methods

System Analysis and Design Page 54

Package diagram - structuring the major components High level diagram in UML to associate classes of related groups Identifies major components of a system and dependencies Determines final program partitions for each layer Can divide into subsystem and show nesting within packages. Implementation issues for three layer design Construct system with programming Integration with user interface design, database design, and network design Use object responsibility to define program responsibilities for each layer Summary Systems design is driven by use cases, design class diagrams, and sequence diagrams Domain class diagrams are transformed into design class diagrams Sequence diagrams are extensions of system sequence diagrams (SSDs) System sequence Diagrams Capture method signatures Show Navigation Visibility Package Diagrams show subsystem organization and dependencies Design patterns are useful solutions to standard programming problems Use case controller (MVC pattern) Adapter Factory and singleton Observer

System Analysis and Design Page 55

Week 12
Friday, 21 October 2011 10:08 AM

There are 5 important principles in modelling and development Abstraction: The process of extracting core principles from a set of facts or statement. Models and modeling An abstraction of something in the real world, representing a particular set of properties. Patterns: Standard solution to a given problem or templates that can be applied to a problem Reuse: Building standard solutions and components that can be used over and over again Methodologies: a process - including the rules, guidelines, and techniques - that define how systems are built. Adaptive approaches to development Opposite end of the spectrum from the predictive approach. Allows for uncertainty Uses empirical controls rather then predictive controls Adaptive approach has: Less emphasis on up front analysis, design, and documentation. More focus on incremental development More user involvement in project teams Reduceddetail planning Tightly controled shedules by fitting work into discrete tome boxes More use of small work teams that are self organizing. The Unified Process (UP) Object oriented system development methodology. Should be tailored to organizational and project needs Highly iterative life cycle Project will be use-case driven and modeled using UML

UP life cycle 4 phases Inception - development and refine system vision Elaboration - define requirements and design and implement core architecture Construction - continue design and implementation of routine, less risky parts Transition - move the system into operational mode.
UP defines disciiplines used within each phase. Discipline - set of functionally related development activities 6 main UP development desciplines Business modeling, requirements, design, implementation, testing, and deployment 3 additional support disciplines Project management, configuration, and change management and environment. Agile development principles A philosophy and set of guildlines for developing software in an unknown, rapidly changing environment Requires agility - being able to change direction rapidly, even in the middle of a project.
System Analysis and Design Page 56

Requires agility - being able to change direction rapidly, even in the middle of a project. Agile modeling principles A philosophy about how to build models, some of which are fomral and detailed and others are sketchy and minimal. Use models as 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. EXTREME programming An adaptive, agile, development methodology. Takes proven industry best practices and focuses on them intensely. Combines those best practices in a new way to produce a result that is greater then the sum of the parts. XP core values Communication In open frequent verbal discussions Simplicity In designing and implementing solutions Feedback On functionality, requirements, designs, and code. Courage In facing choices such as throwing away bad code or standing up to a too tight schedule.

XP practices Planning Users develop a set of stories to describe what the system needs to do Testing Tests are written before solutions are implemented Pair programming Two programmers working together Simple designs KISS and design continuously Refactoring Improving code without changing it Owning the code collectively Continuous intigration System metaphor On site cutomer Small releases Fourty hour work week Coding standards
XP project activities System level activities Occur once during each development project Involve creating user stories to planning releases Release level activities Cycle multiple times, once for each release Are developed and tested in a period of no more then a few weeks or months. Iteration level activites Code and test a specific functional subset in a few days or weeks Scrum A quick adaptive and self organizing development methodology
System Analysis and Design Page 57

A quick adaptive and self organizing development methodology Responds to a situation as rapidly and positivly as possible Scrum philosophy Responsive to a changing, dynamic environment Focuses primarily on the team level Uses a product backlog as the basic control mechanism 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 the work among themselves Scrum practices Sprint The basic work process in scrum A time controlled miniproject 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 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 Project communication management Critical because of open verbal communication and collaborative work Project quality management Continual testing and refactoring must be scheduled Project risk management High risk aspecs addressed in early iterations Project human resource management Teams organize themselves Project procurement management Intergrating purchased elements into the overall project Verifying quality of components Satisfying contractual commitments Model-Driven Architecture (MDA) is an OMG (Object Management Group) initiative Built on the principles of abstraction, modeling, reuse and patterns Provides companies with a framework to identify and classify all system development work being done in an enterprise Platform independent model (PIM) Describes system characteristics that are not specific to any deployment diagram Uses UML Platform specific model (PSM)
System Analysis and Design Page 58

Platform specific model (PSM) Describes system characteristics that include deployment platform requirements Object frameworks A set of classes that are designed to be reused in a variety of programs The classes within an object framework are called foundation classes Object frameworks types User interface classes Commonly used objects within a GUI Generic data structure classes Linked lists, binary trees, and so on, and related processing operations Relational database interface classes Classes to create and perform operations on tables Classes specific to an application area Impact on design and implementation Frameworks must be chosen early in the project Systems design must conform to specific assumptions about application program structure and operation that the framework imposes Design and development personnel must be trained to use a framework effectively. Multiple frameworks might be required, necessitating early compatibility and integration testing Components Software modules that are fully assembled and ready to use Have well defined interfaces that connect them to clients or other components Standardized and interchangeable Component standards and infrastructure. Interoperability of components requires standards to be developed and readily available

Components might also require standard support infrastructure Networking standards are required for components in different locations
Components and development life cycles Component purchase and reuse is a viable approach to speeding completion of a system Standards and support software of purchased components must become part of the technical requirements definition A components technical support requirements restrict the options considered during software architectureal design Examine component based designs to estimate network traffic patterns and demands on computer hardware Examine existing server capacity and network infrastrucure to determine their ability to accommodate communication among components Upgrade network and server capacity prior to development and testing Test system performance during development and make any necessary adjustments Countinously monitor system performance, after deployment to detect emerging problems Redeploy components, upgrade server capacity, and upgrade network capacity to reflect changing conditions Summary Adaptive development methodologies
System Analysis and Design Page 59

Adaptive development methodologies Unified Process (UP) Agile modeling and agile development Flexible in an unpredictable business world EXTREME programming Tests are written first, programmers work in pairs Scrum Defines a specific goal that can be completed within 4 weeks Model Driven Architecture Provides techniques for larger organizations to intergrate all software and all software development across the entire enterprise Software reuse is a fundamental approach to rapid development Object frameworks provide a means of reusing existing software through inheritance Components are units of reusable executable code that behaves as distributed objects.

System Analysis and Design Page 60