ITM 305 Notes for ENTIRE COURSE.docx
Premium

33 Pages
793 Views
Unlock Document

Department
Information Technology Management
Course
ITM 305
Professor
Tim Mc Laren
Semester
Fall

Description
ITM 305 NOTES Week 2: Chapter 1: introduction to systems development SDLC Information systems development process Agile development  Neither team members nor the user completely understands the problems and complexities of a new system  Be responsive to unanticipated issues  Agile and flexible  Allow, anticipate, embrace changes and new requirements during development process Iterative development  “grown” in an organic fashion  Piece by piece  Core components developed first, additional components are added  One big project, with many mini-projects Week 2: Chapter 8: Approaches to System Development Predictive approach to the SDLC  Can be planned and organized  New information system can be developed according to the plan  Phases o Project initiation o Project planning o Analysis o Design o Implementation o Deployment o support  Waterfall model o Assumes phases can be carried out and completed sequentially o No going back o Rigid planning, final decision-making at each step Adaptive approach  Assumes project must be more flexible and adapt to changing needs as project progresses  System requirements needs aren’t well understood  Cant be planned completely   Spiral model o Some analysis, some design, some implementation o More analysis, more design, more implementation o Even more analysis, even more design, even more implementation Incremental  Based on iterative life cycle  System is built in small increments Walking skeleton  Provides complete front to back implementation of the new system but with only “bare bones” of functionality  Later adds flesh  Gets working software into hands of the user early  Extensive user texting and feedback  Iterative is also adaptive Predictive waterfall includes a support phase but adaptive and iterative SDLCs don’t System development methodology  Set of comprehensive guidelines for SDLC  Includes models, tools, techniques Models  Record or communicate information  Representation of an important aspect of the real world o Inputs, outputs, processes, data, objects, object interactions, locations, networks, devices o Gantt chart Tools  Software support that helps create models or other components required in the project Integrated development environments  Includes many tools to help with programming  Smart editors, context-sensitive help, debugging tool Visual modeling tools Techniques  Collection of guidelines that helps an analyst complete an activity or task  Step by step instructions for creating a model  Advice  Methodology includes a collection of techniques that are used to complete activities Within each phase of the systems development life cycle. The activities Include the completion of a variety of models as well as other documents and Deliverables. Like any other professionals, system developers use software tools to help them complete their activities. Software construction and modeling  Structured approach o For predictive approach o Programming approach where each module has one start/end point, uses sequence, decision, repetition constructs only  Top-Down Programming o Divides complex program into hierarchy of modules  Structure design, chart, analysis o Loosely coupled o Highly cohesive o Easier to understand what each modules does and whether it affects the outcome of any other modules  Data flow diagram  Object oriented approach o Collection of interacting objects that work together to accomplish tasks Chaordic (chaos and order) Week 3: Chapter 9: Project Planning and Project Management Finishing on time, within budget, effectively meet the need Oversight committee – clients and key managers who review the progress and direct the project Ceremony -level of formality of the project PMI(Project Management Institute) Agile Project Management (APM) PMBOK (Project Management Body of Knowledge  Project scope management  Time  Cost  Quality  Human resource  Communications  Risk  Procurement  Integration System vision document (scope)  Problem description  Anticipated business benefits  System capabilities Business benefits – contains the results that the org. anticipates it will accrue from a new system System capabilities – support the realization of the beliefs, helps identify the size and complexity of the new system and project that will be required Net present value Payback period Tangible benefit Intangible benefit Determine project risk and feasibility, review with client and obtain approval Establish project environment, schedule work, staff and allocate resources Evaluate work processes, monitor, make corrections Week 3: Chapter 2: Investigating System Requirements Technology architecture  The set of computing hardware, network hardware, and topology, and system software employed by the org. Application architecture  The info systems that supports the org. (info systems, subsystems, and support tech) Consolidated Sales and Marketing System (CSMS)  Goal is to modernize technology and functionality  Add more customer-oriented functionality  Four subsystems o Sales subsystem o Order fulfillment subsystem o Customer account subsystem o Marketing subsystem System analysis activities  Gather detailed information  Define requirements  Prioritize requirements  Develop user-interface dialogs  Evaluate requirements with users System requirements – the activities a system must perform or support and the constraints that the system must meet  Separate into functional/non-functional requirements Functional requirements – the activities that the system must perform  Business functions the users carry out, use cases Non-functional requirements – characteristics of the system other than those activities it must perform or support  Constraints and performance goals To differentiate functional and non-functional use FURPS  Functional requirements  Usability requirements  Reliability requirements  Performance requirements  Security requirements Model - representation of some aspect of a system Textual models – something written down, describes requirements, detailed Graphical models – use pictures for graphs, layouts, maps Mathematical models - -use numbers, formulas, algorithms Unified Modeling Language (UML) – standard set of model constructs and notations defined by the Object Management Group Stakeholders – ppl w/ interest in successful implementation of system  Internal (persons inside org.)  External (persons outside org.)  Operational (regularly interact w/ system)  Executive (use the info for financial interest) Gathering information  Interviews w/ users and stakeholders  Distribute and collect questionnaires  Review inputs, outputs, and documentation  Observe and document business procedures  Research vendor solutions  Collect active user comments and suggestions Documenting workflows with activity diagrams  Workflow – sequence of processing steps that completely handles one business transaction or customer request  Activity diagram – describes user/system activities, sequential flow Week 4: Chapter 3: Use Cases Use case – an activity that the system performs, usually in response to a request by a user  User goal technique o Determines what specific goals/objectives must be completed by a user  Identify all potential users  Classify potential users in terms of their functional role  Classy potential users by organizational level  Identify their goals  Organize use cases by type of user  Look for duplicates/inconsistencies  Identify where different types of users need same use cases  Review  Event decomposition technique o Determines the external business events to which the system must respond  External event  Temporal event  State event o Event vs sequence of prior conditions to an event o Perfect technology assumption  External events to look for include:  √ External agent wants something resulting in a transaction  √ External agent wants some information  √ Data changed and needs to be updated  √ Management wants some information  Temporal events to look for include:  √ Internal outputs needed  √ Management reports (summary or exception)  √ Operational reports (detailed transactions)  √ Internal statements and documents (including payroll)  √ External outputs needed  √ Statements, status reports, bills, reminders For state events, what will the system respond to, internal state changes trigger use cases  Do not use events that involve login, logout, change pass, backup, restore CRUD (create, read, update, delete) archive  Technique to validate, refine, cross-check use cases o Identify all data entities/domain classes involved in new system o Verify that a use case has been identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes an instance Use Case Diagram Steps  Identify all stakeholders and users who would benefit by seeing a use case diagram  Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use cases that are of interest  For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams  Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users Week 5: Chapter 5: Extending the Requirements Model Use Case Diagram – lists and describes the processing details of a use case  Use case name  Scenario  Triggering event  Brief description  Actors  Related use cases  Stakeholders  Preconditions  Post conditions  Flow of activities  Exception conditions Scenarios/ use case instances Interaction diagram – shows interaction between actors and objects within the system System Sequence Diagram (SSD) – showing the sequence of messages b/w an external actor and the system during a use case /scenario  UML sequence diagram (unified modeling language) SSD Notation  Lifeline  Loop frame  True/false condition  Opt frame (based on true/false condition)  alt frame (if/then else condition) Developing SSD 1. identify input message 2. describe message from external actor to the system using message notation 3. identify special conditions on input messages 4. identify and add output return values State Machine Diagram – shows the life of an object in states and transitions  state  transition  action expression  pseudo state (starting point)  origin state  destination state  guard condition Concurrent states Composite states Concurrent Paths (multiple paths in concurrent states) Developing State Machine Diagram 1. review the class diagram, select classes that might require state machine diagrams 2. make list of status conditions 3. identify transitions 4. sequence the states in correct order 5. review paths and look for independent concurrent paths 6. look for additional transitions, test both directions 7. expand each transition with appropriate message event, guard condition, action expression 8. review and test state machine diagram MIDTERM Chapter 4: Domain Classes Problem domain  The specific area of the user’s business need that is within the scope of the new system “Things” (domain classes)  Those items users work with when accomplishing tasks that need to be remembered  Products, sales, shippers, customers, invoices, payments Brainstorming Technique  Use checklist of all usual types of things typically found and brainstorm to identify domain classes of each type Steps 1. Identify user & set of use cases 2. Brainstorm to identify things involved when carrying out the use case—which information should be captured by the system. 3. Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember? Noun Technique  Identify all nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember  finding, classifying, refining a list of nouns that come up in discussions or documents  Popular, systematic  Ends up with long lists + many nouns that may not be used  Difficult identifying synonyms and things that are really attributes  Good place to start when there are no users available to help brainstorm Steps 1. Using the use cases, actors, and other information about the system— including inputs and outputs—identify all nouns.  For the RMO CSMS, the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation… 2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed.  For the RMO CSMS, these might include price, size, color, style, season, inventory quantity, payment method, and shipping address. Details about Domain Classes  Attribute – one piece of information about each instance of the class o Customer has first name, last name, phone number  Identifier or key – one attribute that uniquely identifies an instance of a class, required for data entities, optional for domain classes  Compound attribute – two or more attributes combined into one structure to simplify the model o Address rather than number, street, city, state, zip separately CLARIFICATION!  Called association on class diagram in UML o Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many o We are emphasizing UML in this text  Called relationship on ERD in database class o Cardinality is term for number of relationships in entity relationship diagrams: 1 to 1 or 1 to many  Associations and Relationships apply in two directions o Read them separately each way o A customer places an order o An order is placed by a customer Minimum & Maximum Multiplicity  Associations have minimum & maximum constraints o If mini = 0, association is optional o If mim > 1, association is mandatory Types of Associations  Binary association o Two diff classes  Course section includes students  Members join club  Unary association (recursive) o b/w 2 instances of the same class  person married to person  part is made using parts  ternary association (three)  n-ary association (b/w n) Semantic Net  shows instances and how they are linked The Domain Model Class Diagram  class o category of classification used to describe a collection of objects  domain class o classes that describe objects in the problem domain  class diagram o a UML diagram that shows classes with attributes and associations (plus methods if it models software classes)  domain model class diagram o a class diagram that only includes classes from the problem domain, not software classes so no methods Domain Class Notation  domain class has no methods  class name is always capitalized  attribute names are not capitalized and use camelback notation More Complex Issues about Classes  generalization/specialization o a hierarchical relationship where subordinate classes are special types of superior classes  superclass o the superior or more general class in a generalization/specialization hierarchy  subclass o the subordinate or more specialized class in a generalization/specialization hierarchy  inheritance o the concept that subclasses inherit characteristics of the more general superclass More Complex Issues about Classes: Whole Part Relationships  Whole-part relationship— a relationship between classes where one class is part of or a component portion of another class  Aggregation— a whole part relationship where the component part exists separately and can be removed and replaced (UML diamond symbol, next slide) o Computer has disk storage devices o Car has wheels  Composition— a whole part relationship where the parts can no longer be removed (filled in diamond symbol) o Hand has fingers o Chip has circuits Three types of UML Relationships  Association Relationships  Whole Part Relationships  Generalizations/Specialization Relationships o inheritance Entity Relationship Diagrams CARDINALITY SYMBOLS  An ERD shows basically the same information as a domain model class diagram  It is not a UML diagram, but it is widely used by data analysts in database management  There really is no standard notation, but most developers use the entity and crows feet notation shown in this text  An ERD is not good for showing generalization/specialization relationships and whole part relationships    Ch 10: Object-Oriented Design: Principles  OO design: process by which a set of detailed OO design models are built to be used for coding  Design models are created in parallel to actual coding/implementation w/ iterative SDLC  Agile approach says create models only if they are necessary  Simple detailed aspects don’t need a design model before coding  UML Requirements vs Design Models o Diagrams are enhanced and extended  Architectural design o Enterprise level system  A system that has shared resources among multiple people or groups in an organization o Options are client-server or internet based  Each presents different issues  Component diagram o Type of design diagram that shows the overall system architecture and the logical components within it for how the system will be implemented o Identifies logical, reusable, transportable system components that define system architecture o Essential element of a component diagram is the component element with its API o  Application program interface (API) o The set of public methods that are available to the outside world  Detailed design (use case realization) o Design and implement use case by use case  Sequence diagram – extended SSD w/ added controller + domain classes  Design class diagram – extend from domain model class diagram and update from sequence diagram  class definition – written in the chosen code for the controller and the design classes  UI classes – forms/pages are added to handle user interface b/w actor + controller  Data Access Classes – added to handle domain layer requests to get/save data to the database  Design Classes in Detailed Design o Elaborate attributes – visibility, type, properties o Add methods + complete signatures  OO Detailed Design Steps   Design Class Diagrams o Stereotype – way of categorizing a model element by its characteristics, indicated by guillemots (<<>>) o Persistent class – class whose objects exist after a system is shut down (date remembered) o Entity class – design identifier for a problem domain class (usually persistent) o Boundary class/view class – class that exists on a system’s automation boundary, such as an input window for, or web page o Control class – class that mediates b/w boundary classes and entity classes acting as switchboard b/w view layer and domain layer o Data access class – class that is used to retrieve data from and send data to a database  Class Stereotypes in UML   Notation for a Design Class (syntax for name, attributes, methods)   Notation for Design Classes o Attributes  Visibility ( + not public or - private) whether attribute can be accessed directly by another object  Attribute name – lower case camelback notation  Type expression – class, string, integer, double, date  Initial value – if applicable the default value  Property – if applicable, such as {key}  Ex:  - accountNo: String {key}  -startingJobCode: integer = 01 o Methods o Visibility—indicates (+ or -) whether an method can be invoked by another object. Usually public (+), can be private if invoked within class like a subroutine o Method name—Lower case camelback, verb-noun o Parameters—variables passed to a method o Return type—the type of the data returned o Examples: +setName(fName, lName) : void (void is usually let off) +getName(): string (what is returned is a string) -checkValidity(date) : int (assuming int is a returned code)  Notation for Design Classes o Class level method – applies to class rather than objects of class (static method) is underlined  +findStudentsAboveHours(hours): Array  +getNumberOfCustomers(): Integer o Class level attribute—applies to the class rather than an object (aka static attribute). Underline it.  -noOfPhoneSales: int o Abstract class– class that can’t be instantiated. o Only for inheritance. Name in Italics. o Concrete class—class that can be instantiated.  Notation for Design Classes (method arguments and return types not shown)   Notation for Design Classes (navigation visibility) o Ability of one object to view + interact w/ another object o Accomplished by adding an object reference variable to a class o Shown as arrow head on association line o  Navigation Visbility Guidelines o One-to-man
More Less

Related notes for ITM 305

Log In


OR

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


OR

By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.


Submit