System Development Process

1. System Development Process • A set of activities that applies to all software projects regardless of their size or complexity • Includes activities, methods, best practices, deliverables, and tools that stakeholders use to develop and maintain information systems and software • There is no ‘ONE PROCESS STANDARD’ • Matured organizations have ‘more’ consistent processes • Experience shows that ‘well managed’ software processes lead to least cost software development • One of the most well known framework is the CMM IST321 Ch3

2. Why worry about software process? • Need to move software from an art to science IST321 Ch3

3. Capability Maturity Model (CMM) • Developed by the Software Engineering Institute • Process maturity is specified in 5 levels • Level 1 Initial • Level 2 Repeatable • Level 3 Defined • Level 4 Managed • Level 5 Optimizing • Level 5 indicates most matured software development process • Maturity level is considered as an effectiveness indicator IST321 Ch3

4. What are these CMM Levels • Initial - • Adhoc and occasionally chaotic development process • Few processes are formally defined • Software is ‘successfully’ completed due to individual & sometimes heroic effort • Repeatable • Basic Project Management practices are used including tracking cost, and schedule • Repeat previous success • Defined • Documented process of software management and engineering • Standardization of process and engineering practices IST321 Ch3

5. What are these CMM Levels • Managed • Detailed measurement of product quality and process • Quantitative evaluation methods and tools • Optimizing • Continuous process improvement • Defect prevention • Technology change management • Process change management • Feedback loop IST321 Ch3

6. Life Cycle and Methodology • System Development Life Cycle - Development processes are often derived from a system life cycle • Provides a framework to organize a large number of activities that the development process incorporates • Usually divided into phases and each phase into activities • Phases are usually presented as a sequential set with each phase ending with a set of deliverables • A number of life-cycle models exist: Waterfall Model, Spiral model • Each model has its own terminology even though they all strive to present the same information IST321 Ch3

7. Life Cycle and Methodology • System Development Methodologies - Refer to tools and techniques used to complete tasks of various phases. • We may use structured design technique to design computer programs; the technique would be a methodology where as system design is a phase of the life cycle • A matured organization should use methodologies such that its life cycle process is at least repeatable and well defined • A number of commercial tools are available to support system development methodologies • Information Engineering workbench • Oracle Designer • Arthur Anderson Method and Design tools IST321 Ch3

8. Basic Success Factors of a System Development • System owners need to be champions of the proposed system • Methodologies used should be geared towards problem solving • Intermediate mile stones should be established and outcomes should be measurable • Project must adopt consistent standards for practice and documentation - has a significant impact of the capability maturity of an organization • Establish procedures for the revision of scope; don’t be afraid to cancel or revise, if necessary • Keep scalability and the ability to change in mind; all systems decay (entropy) • Systems should be justified as capital investment IST321 Ch3

9. How systems get started and approved • Can be classified into 3 categories • Problem recognition • Recognition of opportunity • Legal or management fiat • PIECES framework of James Wetherbe • P need to improve performance • I need to improve information • E need to improve economics • C need to improve control or security • E need to improve efficiency of people and processes • S need to improve service to customers, suppliers etc IST321 Ch3

10. How systems get started and approved • Many projects are initiated in an unplanned manner • Approval of these projects often depend upon budget and perceived contribution • More systematic approach is through Strategic IS plan • Strategic IS plan is made to support organizational strategic plan • The fit of a specific proposal is the basis of a project’s approval • Approval may be the responsibility of individuals, but more often that of a steering committee IST321 Ch3

11. Life Cycle Phases • Preliminary Investigation phase • Problem Analysis phase • Requirement Analysis phase • Decision Analysis phase • Technical Feasibility • Operational Feasibility • Economic Feasibility • Schedule Feasibility • Risk Feasibility • Design Phase • Construction Phase • Implementation Phase IST321 Ch3

12. Cross Life Cycle Activities • Activities that are common to many phases of the life cycle • Fact Finding - information gathering • Documentation and Presentation • Project Management IST321 Ch3

13. Phase Principles • Each phase is associated with a set of tasks • Each phase has a set of deliverables • Mile stones and budgets can be associated with these deliverables • Each phase has some participants with well defined roles • There are risks associated with each phase • Output of one phase is generally the input to the next phase • Presented sequentially, in reality, not IST321 Ch3

14. Preliminary Investigation Phase • Consider the feasibility of the proposed system • Technically? Financially? Organizationally? Timely? • Determine scope, size, preliminary budget, time frame • Gathering information is necessary - quickly done with minimal determination • The analyst often talks to key personnel at this stage - system owner and technical leadership of IS organization • Outcome: An initial feasibility report, with some alternative solutions, and initial project parameters • Should we carry out feasibility for all systems? IST321 Ch3

15. Problem Analysis Phase • Often the beginning of an analysis process • Analyst need to understand the scope in detail • System users and owners are integral part of the study process, since only they have the complete information • Results in an updated system scope definition • System owners have an opportunity to reassess their go/no go decision • We will look at information gathering techniques next in some detail before moving on to other phases IST321 Ch3

16. Information Gathering • Techniques • Sampling of existing documentation • Research and site visits • Observation of the work environment • Questionnaire • Interviews • Often, more than one techniques is used in a project IST321 Ch3

17. Sampling of Documentation • Objective is to understand policies, procedures, techniques and data used to complete business operations • Type of documents to be studied • Standard reports, data gathering forms, procedure manuals • Database and file system architectures • Existing project dictionaries, documentation • Organizational policies, plans as applicable • No cook book approach exists, judgment is needed to select • Sampling can be used to select documents, however it is more desirable to have a ‘sample’ of every document type IST321 Ch3

18. Research and site visit • Analyst can gain from the experience of others • Site visit can lead to an understanding of the operational environment • Research resources may include • Standard library search • Use of the World Wide Web • User groups • Published reports of other comparable organizations IST321 Ch3

19. Observation of the work environment • Analyst can gain a first hand knowledge regarding the operational practice or the setting in which the system may be used • Advantages • Data gathered can be highly reliable • Physical conditions of work, decision making etc • Disadvantages • Beware of the Hawthrone effect • Observation time may not coincide with peak effort level • Seasonality and cyclic patterns may be missed IST321 Ch3

20. Observation of the work environment • A detailed planning should be done for observation • who should be observed? • When do the observation take place? • How does the schedule match with normal work flows • Observation should not lead to work disruption • Necessary authorization must exist for conducting an observation session IST321 Ch3

21. Questionnaire • The best method to collect responses from a very wide range of people • Usually inexpensive, but one has to be careful about the response rates • Lacks the depth and intimacy of observation, but benefits from the anonymity a respondent enjoys • Questionnaires tend to be inflexible, and suffers from the possibility of missing important details • Lengthy questionnaires are ignored • Bias in the questions are highly undesirable IST321 Ch3

22. Questionnaire • Questionnaires can be open-ended or structured • Structured questions are easy to answer and analyze, but often the depth of understanding is sacrificed • Open-ended questions allow more in-depth information gathering, but often prove difficult to analyze and aggregate IST321 Ch3

23. Interviews • Perhaps the best method of information gathering since each topic can be studied in detail • Time-consuming and often expensive • Interviewer bias, if any, can seriously taint the collected data • Format of interviews are similar to questionnaires - open-ended vis-a-vis structured • Interviewer should be well prepared, with subjects defined ahead of time • Objectives must also be clearly defined IST321 Ch3

24. Requirement Analysis Phase • Sometimes called Systems Analysis • Objective is to define the scope of the system - what the system must do and not how it will be done • Desired capabilities • Business requirements it must support • Usually involves significant interaction with the user to find DATA, PROCESS, INTERFACE, and GEOGRAPHY requirements of the system • Information gathering techniques are applied • The information gathered is synthesized into a proposed system requirement model IST321 Ch3

25. Decision Analysis Phase • What part of the requirement should be computerized? • Make or buy decision • Propose a preferred architecture with supporting feasibility analysis • technical • operational • econmic • schedule • risk IST321 Ch3

26. Decision Analysis Phase • Issues to be settled • What portion of the system should be computerized • What is the business process interface between the computerized portion and others • What is the proposed architecture of the system • batch, online, realtime • hardware boundaries • Geographic boundaries - communication needs • Centralized or decentralized database IST321 Ch3

27. Design Phase • Often considered as the detailed design phase • Precondition: Approved system architecture and system’s requirement specification • Focus is on components to be developed or integrated • Major activities include • Detailed database design • Detailed application program design • Design of interfaces and dialogs • Classical methodologies may be used: structured charts, object-diagrams • May employ CASE tools • RAD or rapid application development is now being preferred for many systems IST321 Ch3

28. Construction Phase • Detailed coding • Unit testing • Integration and System testing IST321 Ch3

29. Implementation • Install at customer premises • Acceptance testing • Minor tuning as necessary Operation and Support • Technical and user support • Training • Maintenance and minor enhancements IST321 Ch3

30. Model-Driven Development • A number of models are used during the life cycle phases • Structured Analysis - a process-oriented technique used to model a system’s requirements: Data Flow Diagrams • Structured Design - A design tool used to transform structured analysis model to structured design models: Structured Charts • Object-oriented analysis and design (OOAD) - Model is developed using ‘objects’ and their interaction • Advantages • Better planning and documentation of the requirements • Extensive use of graphical tools - tends to improve communication with users • Alternative architectures are relatively easy to generate • Disadvantages • Tends to be complex for large projects IST321 Ch3

31. RAD • Often uses prototyping approach • Prototyping technique require that we build a ‘prototype’ of the proposed system using modern tools rapidly • The prototype itself may become the system, or may serve as the model for the system • Activities • Define the scope • Define, design, construct the database and UI • Exercise the system • Take feed back, modify, and reexercise • Continue until users are satisfied • Move on to the next level of scope and repeat process • Drawbacks? Advantages? IST321 Ch3