Date post: | 16-Dec-2015 |
Category: |
Documents |
Upload: | timothy-davidson |
View: | 221 times |
Download: | 4 times |
2
Textbooks
Required:
Advanced Use Case ModelingFrank Armour and Granville MillerAddison Wesley, ISBN 0201615924
Optional but highly recommended:
Modern Database Management, Hoffer, Prescott and McFadden, 8th edition, Prentice Hall, ISBN 0132212110
3
My Background• Started as New faculty at AU in Fall’02
• Previously at Carnegie Mellon University
• PhD and MS in IS from Carnegie Mellon
• Also, BS Mech Engineering & MBA
• Over 18 years of working experience
• Mostly implementing and managing systems
• And in management
• Specialty: systems implementation and database
• Mostly in international/global contexts
• Teach: MIS, Systems Analysis, Database
• Research focus: • IT support for global & geographically distributed collaboration
• Most recently: team coordination across time zones
4
Contact
• Office: KSB 33
• Office Hours: Mo 1:30 – 5 PM Th 1:30 – 4 PM
• Office Tel: 202-885-1958
• Fax: 202-885-1992
• E-mail: [email protected]
5
Class Web Site
• Current versions of syllabus, class schedule, lecture notes, and homework assignments will be posted on the Blackboard class web site.
• Course Syllabus also available at:http://auapps.american.edu/~alberto/itec630/syllabus.html
• Class Schedule also available at:http://auapps.american.edu/~alberto/itec630/schedule.html
• All homework assignments, lecture slides, and other class materials will be available via the Class Schedule link above, and also via Blackboard
• Class announcements and grades will be available via Blackboard only
7
What is business analysis?
“The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.”
Source: International Institute of Business Analysis (iiBA)
8
About the BusinessAnalysis Profession
• Business analysts used to be called “systems analysts”
• Business analyst is the preferred title today in recognition of the fact that business strategies and system implementations need to be tightly aligned, so the analyst needs to thoroughly understand business goals, functions and processes, more than systems per se (CIO Magazine)
• A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems (iiBA)
• The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals (iiBA)
9
Business Analysis Skills
Ability to develop a thorough understanding of:
• the requirements to solve a business problem, often with a system implementation
• how the proposed system or solution will interoperate or integrate with the existing systems and technology in which the new system will operate.
• how the proposed system or solution fits the existing enterprise architecture and business strategies
• the business problem from multiple perspectives: business, user, functional, quality of service, implementation, etc.
11
About Business Data Design
• Solutions to business problems often involve managing and processing business data into useful information
• Important business data design skills – ability to:o Discover data objects that need to be collected and their data elementso Design the most appropriate structure or schema for the datao Design the most appropriate relationships among data objectso Describe the data accurately with appropriate models for implementation
Design Goals -- data collected: is consistent with the business requirements and enterprise architecture; is correct and accurate; has integrity, both within each data object and in how it relates to other objects; and has no redundancy that could cause inconsistent information
o Discovering the queries necessary to support the creation, retrieval, and manipulation of data for the business application being implemented
• There more than one paradigm for data design: relational database model, object oriented databases, object-relational, etc.
13
What is Information Technology (IT) for Business?
=
IT Infrastructure: the hardware, system software, telecommunications/networks and data storage
supporting all business applications
+
Business Applications: software used to manage particular business functions or processes (e.g.,
accounting, supply chain management)
14
What is an Information System (IS) for Business?
An arrangement of people, business functions, processes, and IT that interact to collect, store
and process, and store data to provide information to support business activities and
processes –
It is more than just IT!!
15
Information Systems
IT Infrastructure(HW, System SW, database, telecom)
IT for Business
BusinessApplications
(ERP, CRM, SCM, Financial Appl, etc.)
People,Processes& Business Functions
+ +
IS =
Business Value !!
16
Information Technology (IT) and Business
Business WorldTransactions
Transaction ProcessingB
usi
nes
sA
ppl
ica
tion
sIT
Infr
ast
ruct
ure
Database
Mainframes
InformationDecision SupportDistributed CollaborationEnterprise CollaborationFinancial Management
etc.
ERP, SCM, CRM, etc.
Microcomputers
(Local/Wide area) Networks
Client Appl
ServerAppl
Client/Server Computing
Distributed Computing
DB DB
Ubiquitous Computing
Security,Firewalls
Inter-Networking (Internet, Intranets)
Virtual Private Networks
Routers
ITEC630
17
Requirements for a Cool House:(first meeting with the client:
a very high level description of the house)
• 3 bedrooms, dinning room, living room, kitchen, laundry room, 2-1/2 bathrooms
• Back patio, access from the kitchen• 2-floors + basement• 2-car attached garage w/extra room on top & driveway• Landscaped front yard & small trees in the backyard• 2 windows, one on each side of front door• 2 windows on 2nd floor above with 1st floor windows• 2 small windows above garage on extra room
20
A Cool House: The Blueprints(very specific dimensions to discuss w/client and
then give to builders for construction: i.e., communicating client requirements)
21
SYSTEM DEVELOPMENT
All the activities that go into producing and IS solution:
0. Vision1. Analysis2. Design3. Implementation4. Testing5. Conversion6. Production & Maintenance
Degree of ceremony or formality?Depends on size, risk,
ITEC630
22
1. Analysis
A communication exercise between system users and system developers
An analysis of the “problems” to be solved by an information system
Developing an understanding of “the work” that the system needs to perform
Developing an understanding of “what” the system needs to do
23
Analysis Involves:
Feasibility Analysis: • System concept, project blastoff• Technical, economical & operational feasibility
Risk Analysis:• Identifying (technical, project & business) threats to the viability of
the system and the probability that they materialize• Affected by system size, business impact, customer characteristics,
software process maturity, development environment, technological complexities, development staff experience, etc.
Requirements Analysis:
Understanding the work that the system needs to do and, the qualities the system must have
ITEC630
24
Requirements Analysis
• Functional (Behavioral) Requirements – what the system needs to do: “The work”
• Non-functional Requirements – the qualities of the system (e.g., speed, reliability, capacity)
• Project requirements – costs, deliverables, deadlines
• Described in the
“System Requirements Specification”
25
Why is requirements analysis so important?
The cost of fixing and error in requirements is:
Times larger If discovered during
5 Design
10 Implementation
20 Testing
100 Operations
Bohem, Barry R. 1981. Software engineering economics. Englewood Cliffs, N.J.: Prentice-Hall.
Errors Propagate and Grow
correctrequirements
wrongrequirements
correctdesign
design based onwrong requirements
wrongdesign
problem
code based onwrong designs
correctcode
wrongcode
code based onwrong requirements
27
2. Design
An analysis of the “solutions” to the problems identified during systems analysis
Developing and understanding of “how” the system needs to do what was identified during systems analysis, per the “requirements specification”
ITEC 630: Business Data Design and Basic Introduction to Interface Design
ITEC630
28
3. Implementation
Selection, acquisition, production and assembly/integration of the necessary components of the system
For systems that require software development, translating the conceptual design into specific software instructions to accomplish the work.
29
4. Testing
Ensuring that the system performs as required
Test types:
• UNIT TESTING: Ensure that each part of the system work well individually
• SYSTEM TESTING: Ensure that all the parts work well together
• REGRESSION TESTING: Ensure that new software work well with the existing software
• ACCEPTANCE TESTING: By users and/or clients
Methods:
• BLACK BOX TESTING: Testing if the system does what is supposed to, per requirements specifications, without inspecting the internals of the system
• CLEAR BOX TESTING: Inspecting and testing the internals of the system (opening the black box)
ITEC630
(Test Cases)
30
5. Conversion (i.e., Installation)
Important Issues:• CONVERSION PLAN: Schedule for conversion• DOCUMENTATION: Description of how system works• USER TRAINING
Conversion Methods:• PARALLEL: Old & new run same problems. Give same
results?• DIRECT CUTOVER: Risky conversion to new system• PILOT: Introduce into one area. Does it work? Yes:
introduce into other area• PHASED: Implement the system in stages
31
6. Production & Maintenance
• PRODUCTION: Review by users & operatorsUser support
• MAINTENANCE: Upgrades
Bug fixes
32
Brooks, 1994 (IBM O/S 360)
33%
17%17%
33%
EFFORT DISTRIBUTION
Systems Analysis & Design
Maintenance
Testing & Integration Implementation
33
Systems Development Models
• Linear Sequential ModelsSystem development progresses in a straight line fashion
• Evolutionary ModelsSystem development is done in iterations
34
System Development Life Cycle (SDLC)or the “Waterfall” Model (Linear Sequential)
Systems Analysis
Design
Implementation
Testing and Conversion
Production & Maintenance
35
SDLC (“Waterfall”) Model Pros & Cons
Pros:• Oldest and most widely used model• Life cycle concept is very useful• OK when requirements are certain and stable
Cons:• Early errors detected late are very costly• Not very useful when requirements are uncertain• Many real projects rarely follow a sequential flow• Often difficult to know all requirements early on• Programmers have to wait until the whole design is finished
36
The Incremental Model(Linear Sequential)
Analysis
Design
Programming
Testing,etc.
Core Product
Analysis
Design
Programming
Testing,etc.
Analysis
Design
Programming
Testing,etc.
Increment 1
Increment 2
Etc.
Integration +Regression Testing
37
Incremental Model Pros & Cons
Pros:• Core functionality can be provided quickly• Increments can be planned to manage technical risks
(e.g., increment, evaluate, increment, evaluate, etc.)
Cons:• Takes a long time to finish entire system• Later increments may never get done
38
The Prototyping Model (Evolutionary)
Identify Requirements
Develop Prototype
Install and Use
User satisfied ?
No
Feedback
Refine Requirements
Develop Full System
Yes
39
Prototyping Model Pros & Cons
Pros:• Good when input/output requirements and user interface
not clear initially• Good for development of “visible” parts of the system• Fosters communication with customers and users• Helps identify and refine requirements
Cons:• False expectations: customer sees what appears to be a
working product• Not good for “invisible” aspects of system• Early unfinished prototypes may perpetuate themselves
40
The Spiral Model (Bohem)(Evolutionary)
Planning
Engineering (Analysis &
Design)
Construction (Implementation)
Testing & Release
(Conversion)
Customer Communication
& Evaluation(Business
Requirements)
RiskAnalysis
41
The Spiral Model
Pros:• Each loop allows the team to assess risks and
adjust the plan• More realistic approach for large projects• Conceptually sound idea
Cons:• Not many – the basic concept is widely adopted• Is the foundation for the Unified Process (UP)
42
Object-Oriented (OO) Analysis
• Most prevalent software system development paradigm today
• In which a system is conceptualized by discovering physical objects that the system needs to represent – e.g., customers, locations, students, classrooms, invoices, etc.)
• And discovering their attributes (i.e., data elements – e.g., name, SSN, etc.) and behaviors (i.e., programs – e.g., place an order)
• More on OO later in the course
43
Standards
Standards are necessary when many people are involved in a system development effort.
There are many types of standards, but two very important ones are standards about: (1) notation and (2) process
• A notation (i.e., a language) is necessary to describe the system. Standard notations describe the symbols to use in models and other analysis artifacts. We will use the UML (Unified Modeling Language)
• A process is necessary to define the sequence of activities that will be undertaken to gather requirements and then design and implement the system: We will use the UP (Unified Process)
44
Unified Modeling Language (UML)
• UML a standard for notations and methods to express OOA/D• UML is the most widely adopted standard diagramming notation to describe
systems today• Proposed by Booch, Jacobson & Rambaugh (the “Three Amigos”) to unify
their individual (most widely used) notationsSee Object Mgt Group site: http://www.omg.org/
• Main purpose of the UML: communication!!• It is intended for OO Analysis and Design (OOA/D)• You can do OOA/D without UML using other notations• Similarly, you can use aspects of UML for non OOA/D• UML is up to version 2.0, textbook UML 1.3, MS Visio UML 1.2
For more info on UML and versions, see: http://www.kobryn.com/
45
Important UML Models
• Use Cases – a set of scenarios of system uses, each tied together by a common user goal
• Activity Diagrams – diagrams that explain use case workflows (sometimes useful, but use case text is often preferred)
• Class Diagrams – describes the types of objects in a system and the static relationships among them
• Domain Model – like a class diagram (and/or other models), but it only shows noteworthy objects and elements, used to provide a conceptual skeleton view of the system
• Interaction Diagrams – models that describe how groups of objects collaborate
• Class-Responsibility-Collaboration (CRC) Cards – text version of interaction diagrams, not part of UML but often used with UML
• State Diagrams – models that describe possible states of objects and how the object’s state changes with events (e.g., order status)
46
The Unified [System Development] Process (UP)
• A system development process defines the activities undertaken to building, deploy, and maintain systems
• UP: a popular SW development process used with OO methods
• UP was also developed by the “Three Amigos”• UML and UP are independent – you can use UML without
UP, or UP without UML, but they were both conceptualize to work together
• Rational UP (RUP): a refinement of the UP formulated by the “Rational Corporation” now owned by IBM, widely adopted today.See: http://www.rational.com/
47
Key Aspects of the UP
• Iterations: “timeboxed” – i.e., of fixed time length of 2-6 weeks – date slippage is discouraged – removing tasks or requirements from the iteration is preferred
• Workshops: each iteration begins with at 1-2 day workshop to discuss the scope of the iteration and plan accordingly.
• 4 Phases: inception, elaboration, construction and transition – this course deals with the inception and elaboration phases
• Disciplines (originally called “workflows” until 2001): a set of related system development activities (e.g., analysis, design, etc. – note: these are considered “phases” in the Waterfall model)
• Artifacts: working products such as code, database schemas, text documents, diagrams, models, etc.
• Development Case: articulates upfront which artifacts (not all artifacts need to be employed) will be used in the particular development project
48
Iterations, Disciplines & Workflows in the UP
Incep Elab 1 Elab 2 etc.
Source: Larman book ch.2, p.21
49
Development CaseFor this Course
Discipline UP ArtifactIncept
I1Elab
E1..EnConstrC1..Cn
TransT1..Tn
Business Modeling Domain Model S
Analysis
Vision S R
Use Case Model S R
Supplementary Spec S R
Glossary S R
Design
Design Model S R
SW Architecture Doc S
Data Model S R
ImplementationImplementation Model S R R
SW Development Plan S R R R
Testing Test Model S R
Dev Environment Development Case S R
S – Start; R – Refine
50
Important Things to Keep in Mind
• Ceremony or Formality: o High ceremony: lots of formal deliverables, meetings, etc.o How much? it depends
• The right process? it varies for each company• Requirements and Design = communication exercises• No need to use all diagrams or artifacts• No need to note everything, only what is noteworthy• Avoid overdoing requirements (i.e., analysis paralysis):
keep it simple, but accurate
Let’s look at the Class Schedule once again
Let’s look at the Final Project