INFO 503 Glenn Booker

1. Introduction to InformationSystems AnalysisInformation Systems DevelopmentFact Finding Techniques INFO 503 Glenn Booker Lecture #2

2. System Development Life Cycle • A System Development Life Cycle is the process used for developing a system • A life cycle is a management tool for planning, conducting, and controlling an activity • Software and System life cycles are similar, differing in the details of each activity Lecture #2

3. Methodology • A methodology, such as FAST, implements a life cycle by defining activities • Each activity has roles and responsibilities, creates work products, and uses tools and techniques • Major recurring theme in the text • Methodology should cover entire life cycle Lecture #2

4. Capability Maturity Model • Level 1 = Initial chaos – no consistent processes • Level 2 = Repeatable processes for a project • Level 3 = Defined processes across an organization • Level 4 = Quantitatively Managed projects • Level 5 = Processes Optimized continuously Lecture #2

5. Groundwork • Any system development should first define its general scope • What kind of product will be created? • What order of magnitude for time frame and number of resources are available for this effort? (e.g. week, month, year, or $10k, $1M) • What is the current state of similar products? • What will make this product special? Lecture #2

6. Ten Principles of System Development • Get the system users involved • Use a problem-solving approach • Establish phases and activities • Document throughout Development • Establish standards • Manage the Process and Projects • Justify systems as capital investments • Don’t be afraid to cancel or revise scope • Divide and conquer • Design systems for growth and change Lecture #2

7. 1. Get the System Users Involved • Encourage owners, users, and developers to work cooperatively and collaborate • Get everyone involved in defining requirements and discussing changes • Document decisions well • Education of owners and users can help overcome biases and fears Lecture #2

8. 2. Use a Problem-Solving Approach • The methodology (life cycle) is an approach • Study the problem and its context • Define the requirements of a solution • Identify possible solutions and pick one • Design and implement the solution • Observe the solution’s impact, and refine it • Don’t skip steps! Lecture #2

9. p. 89 (75) 3. Establish Phases and Activities • Major FAST phases are: • Scope Definition (led by system owners) • Problem and Requirements Analysis (users) • Logical Design and Decision Analysis (designers) • Physical Design and Integration (builders) • Construction and Testing • Installation and Delivery Lecture #2

10. 3. Establish Phases and Activities • Higher levels are business-driven; lower are technology-driven • Each phase is broken down into activities and tasks to make them manageable • Development is often iterative, with frequent back-tracking to refine requirements and the design • Be sure not to get stuck in iteration! Lecture #2

11. 4. Document throughout Development • In order for large projects to succeed, programs need to be documented and agreed upon before they’re developed • Necessary for coordination across stakeholders, and to leave a comprehensible legacy for maintenance Lecture #2

12. 5. Establish Standards • Standards should be used for both creation of the information system itself, and for the processes used to create the system • Records assumptions and measure progress • May include document style standards, file and variable naming conventions, and file organization conventions… Lecture #2

13. 5. Establish Standards • System development standards may describe, for every phase of the life cycle: • Activities (what happened?) • Responsibilities (who did it and why?) • Documentation requirements (tailor from corporate standard templates) • Quality checks (peer review, defect prevention) Lecture #2

14. 6. Manage the Process and Projects • Deliberate process and project management ensures that your organization 1) has defined processes, and 2) they are actually used, and 3) you can determine how to improve them • Benefits not only this program, but others in the future too Lecture #2

15. 7. Justify Systems as Capital Investments • Information systems often outlive many projects, hence are capital investments • Make sure alternatives are well investigated (do you buy the first house you see?) • Analyze the cost-effectiveness of all major alternatives, including both development and operational costs • Manage risks during development Lecture #2

16. 8. Don’t be afraid to Cancel or Revise Scope • The iterative nature of development makes it tempting to implement a not-good system • Feature and schedule creep can sneak up quietly, one good decision after another • Avoid getting stuck by choosing creeping commitment points during development • At each, consider cancellation, projected system cost, schedule, and feature scope Lecture #2

17. 9. Divide and Conquer • Every system is part of a larger system (supersystem) and most contain smaller systems (subsystems) • Interaction with supersystem can change requirements during system development • Defining subsystems can help make project design more manageable Lecture #2

18. 10. Design Systems for Growth and Change • Business needs change over time • During system maintenance (support), maintenance cost grows as the system requirements evolve and hardware wears out; system becomes obsolete • Hence need to design systems so that they can be replaced some day Lecture #2

19. FAST Methodology • An information system project starts when: • Problems keep your organization from reaching its business goals or objectives • Opportunities arise when a new capability is identified (e.g. new features) • Directives from outside your organization mandate new features or requirements (e.g. laws, regulations) Lecture #2

20. PIECES Review Criteria Assess new projects for their: • Performance improvement potential • Information or data improvement • Economic or cost improvement • Control or security improvement • Efficiency improvement (people or process) • Service to customer, supplier, staff, etc. Lecture #2

21. p. 96 (83)key overview FAST Phases • Scope Definition [in 4th Ed.: Survey Phase] (system owner) • Problem Analysis [Study Phase] (analyst) • Requirements Analysis [Definition Phase] (analyst) • Logical Design [not separate in 4th Ed.] • Decision Analysis [Configuration Phase] (designer) Lecture #2

22. FAST Phases Procurement Phase [Version 4 separate only; or blend into other phases] (designer) • Physical Design & Integration [Design Phase] (designer) • Construction & Testing [Construction Phase] (builder) • Installation & Delivery [Delivery Phase] (builder) Lecture #2

23. 1. Scope Definition • This is a sanity check to see if the project is worth looking at • If so, define the project team, budget, and schedule (very rough) • Involves sponsors and managers, plus user involvement • Deliver a feasibility study and project plan Lecture #2

24. 2. Problem Analysis • Study existing system (automated or not) for problems and opportunities • Is the new & improved system worth having? • Run by system analyst, with user and owner involvement • Define system objectives, and success criteria for new system Lecture #2

25. 3. Requirements Analysis • Now define and prioritize detailed system and business requirements • Consider also what it does NOT do • Do NOT describe HOW it does anything • System analyst and many users do this • Create models of data, process, interface, and geography perspectives… Lecture #2

26. 3. Requirements Analysis • Might use prototyping to verify requirements • Present requirements and models in a requirements statement • “Time boxing” is placing requirements into staged deliveries for implementation (hence start to think of priorities) Lecture #2

27. 4. Logical Design • The logical design phase is when various models are developed to describe the logical functions of the system • This typically includes data, process, and/or object models • Beware of getting stuck in analysis paralysis Lecture #2

28. 5. Decision Analysis • Identify candidate solutions, analyze them, and recommend the best one • Done by system analyst, with support from all others, and maybe consultants • May start before requirements are done • May include make-or-buy decisions, and define an application architecture… Lecture #2

29. 5. Decision Analysis • Evaluate each solution for technical, operational, economic, and schedule feasibility • Produce a system proposal for owners’ approval • Often includes procurement phase for off-the-shelf applications Lecture #2

30. Procurement Phase • Major system components are often acquired, not built from scratch • See COTS tool reports (Commercial-Off-The-Shelf software) by the SEI, STSC • Vendors “help” system analyst and users • Study existing market & future trends, then generate a RFP or RFI (see References)… Lecture #2

31. Procurement Phase • Evaluate vendors’ proposals; pick the one that meets requirements and is most cost effective • Negotiate contractual and licensing needs to obtain products, installation, training, etc. Lecture #2

32. 6. Physical Design & Integration • Turn requirements into plans for the builders, iteratively, until plans are complete (Rapid Application Development) • Analyst and specialists involved • Database, program, human and system interfaces are all designed using iterative prototyping… Lecture #2

33. 6. Physical Design & Integration • Iterate: • Define base system • Define database, load with data, and review with users • Define inputs, and review with users • Define outputs, and review with users • Define interfaces, and review with users • Define other controls, and implement. Repeat. Lecture #2

34. 7. Construction & Testing • Now build the real system and its interfaces • System builders lead the team • Design specifications are main input • Write code, then conduct unit test, and system test • May deliver system in stages Lecture #2

35. 8. Installation & Delivery • Install new system and place it into operation • May include data conversion and loading to initialize system, and training of end users • Users provide feedback (problem reports) to identify initial support issues Lecture #2

36. System Operation and Maintenance • While system is in use: • Assist users (help desk) • Fix bugs • Recover system after failures • Adapt to new requirements (implement new features) Lecture #2

37. Cross Life Cycle Activities • These may overlap many (or all) other phases of development • Fact-finding • Help collect information about systems, requirements, and user preferences; • Most important early in life cycle Lecture #2

38. Cross Life Cycle Activities • Documentation is generated to record the work accomplished so far, and plan future activities • Presentations are a formal packaging, in writing or orally, of some documentation • “Dog and pony shows” are presentations made to upper management or sponsors Lecture #2

39. Cross Life Cycle Activities • Estimation and measurement are performed throughout the life cycle (see INFO 630) • Estimation is to predict the amount of time, effort, cost, and benefits of some activity within system development • Measurement is to determine the actual amount of what was estimated • “Earned value” is one way of comparing them Lecture #2

40. Cross Life Cycle Activities • Feasibility analysis is performed early in a project to determine its potential benefits • Recall mention of technical, operational, economic, and schedule feasibility • Project management is the deliberate planning and control of a project to achieve the desired goal (creation of a product) Lecture #2

41. Cross Life Cycle Activities • Process management is the conscious definition and management of the processes used to conduct a project, using standards to define typical work products (deliverables) • Data and documents from all phases should be stored, such as in a repository Lecture #2

42. Methodology Options p. 108 (n/a) • Systems can be build from scratch, purchased off-the-shelf, or some of both • Methodologies can be very rigid (prescriptive), or flexible (adaptive) • Methodologies can be model-driven (draw pictures first, e.g. FAST) or product-driven (build something and see if it works) Lecture #2

43. Model-Driven Development • Most methods for analysis and design focus on using models to capture thoughts • Structured analysis focuses on processes, such as the data flow diagram • Information engineering focuses on data, such as the entity relationship diagram • Object oriented analysis and design blend data and process into objects Lecture #2

44. RAD and COTS • Rapid Application Development (RAD) focuses on iterative development of prototypes with lots of user input • Often uses time boxing to limit the effort on each iteration • Commercial Off The Shelf (COTS) products can be used as the entire system, or significant portions of a developed one Lecture #2

45. CASE Tools • Computer Assisted Software Engineering (or Systems Engineering) tools use an information system (customized database) which is devoted to managing a system development effort • CASE tools may include compilers, design and diagram tools, quality and document management tools, and generate code Lecture #2

46. CASE Tools • Upper CASE Tools focus on early development activities – requirements and high level design phases; may also be able to reverse engineer code • Lower CASE Tools focus on (you guessed it!) later development activities – detailed design, construction (coding), implementation, and perhaps support Lecture #2

47. CASE and ADE Tools • CASE Tools are noted for pretty graphical capabilities - diagrams, flow charts, etc. • They store projects in repositories • Price is high in both $$$ and learning curve • Compilers have evolved into Application (or Integrated) Development Environments (ADE or IDE) – may include debuggers and interface tools, testing and version control Lecture #2

48. Fact Finding and Information Gathering • Fact finding is the formal process of using various techniques to collect information about system requirements and user preferences • Facts are the basis for modeling • Conclusions about the system are also drawn from these facts • So facts are, like, really important :) Lecture #2

49. Fact Finding and Information Gathering • Fact finding is most important during the planning and analysis phases, but still useful during the rest of the life cycle • Seven techniques to choose from; often use several on any given project • Fact finding may also discover business rules – how does the system need to respond under different conditions? Lecture #2

50. Requirements See also INFO627 • Fact finding may give info at various levels of detail, depending on the audience • Requirements capture what and/or how the system needs to be able to support its users • A requirement is more precise than a user need, but more vague than a specification • Defining requirements is a key output from fact finding and information gathering Lecture #2