SUMMARY AND REFERENCE ACTG 313 TASKS IN THE SYSTEMS DEVELOPMENT LIFE CYCLE PREPARATION PHASE 1. Identification of the Need for a new Information System 2. Initial Feasibility Study (always flawed because it s too early in the project!) 3. Determination of the Initial Scope of the Project (including recognition of Scope Creep opportunities) 4. Initial Budget and Timetable (always incomplete because project hasn t been fully spec d yet) 5. Formal Proposal to Management, Approval (beware of arbitrary cuts/revisions by management) 6. Assembly of the Project Team (Dual-Specialty approach: user specialists and technical specialists) 7. Organization of the Project (Work breakdown, assignments, setting of standards, etc.) 8. Development Controls (controls on the SDLC project itself) DESIGN PHASE 9. Definition of User Needs (vs. wants, desires, etc. Good opportunity to re-invent the business processes) 10. Initial Identification of Data Elements (pay attention to what is really a data element) 11. Input/Output Specifications (what elements go where, and come from where) 12. Prototyping Input/Output (extremely helpful to validate, confirm, reject, or explore user requests) 13. Determination of Data Flows, Entity-Relationship models, semantic modeling 14. Initial Data Organization (initial pass at file structure, relationships, etc.) 15. Data Normalization (results in database schema) 16. Development of Data Dictionary (standard for communication intra-team and between team and users) 17. Creation of Processing Specifications (critical importance of Programming Standards set in task 7) DEVELOPMENT PHASE 18. Coding (including compiling if applicable importance of review and supervision) 19. Alpha Testing Regimens a. Debugging Tests (Does the program work according to specification?) b. Module Tests (Do the programs which make up the accomplish their overall purpose?) c. Integration Tests (Do the modules interact with each other properly?) d. Load Tests (Can the system handle the expected volume satisfactorily?) e. Compliance, Control and Security Tests (Legal compliance, audit, operational controls?) 20. Beta Testing (Can the user run his business with this system?) 21. Version Control Processes (for program revisions) & Critical Importance of Test Bed 22. User Signoff on Software Development (usually a formality) IMPLEMENTATION PHASE 23. Hardware Selection, Acquisition, Installation, & Testing (This may be its own sub-project!) 24. Installation of Software on the Production Platform (and re-testing!) 25. User Training (ideally begins during design phase and follows a structured approach) 26. Loading of Initial Data onto Production Platform (or data conversion from old system to new system; This task might be its own sub-project) 27. Cut-Over or Going Live (Modular, Parallel, or Drop Dead ) 28. Shakedown Cruise and Cleanup (bug fixes, ad hoc problems, supplemental training, etc.)
MAINTENANCE PHASE 29. Routine Support (questions, retraining, correcting bad habits, help-desk-operations, rarely-used features, etc.) 30. Changes & Modifications (changes required to keep system current with evolution in laws, business, etc.) DOCUMENTATION (Throughout all phases and tasks of the project) EVALUATION (overlooked or omitted by many project managers) 31. Debriefing at end of project 32. Evaluation several months/years after implementation Additional Notes and Details PREPARATION PHASE NOTES: The Triad of Scope, Resources and Time: You can only specify any two. Specifying any two automatically limits the third. Management often tries to specify all three. This is a recipe for failure. The nature of the Dual-Specialty Team: User specialists know the organization, they know the business, the firm, the employees, the environment, etc. Technical specialists are the programmers, network designers, database architects, systems analysts, and other IT personnel who may or may not be intimately familiar with the organization. There are potential problems inherent in combining technical specialists with business specialists into a single team: Human relations, personalities, cultural clashes, etc. Development controls are critically important. These are the controls on the SDLC itself, and address the quality controls, the security of the development tools, programs, and other protections, as well as project management activities. DESIGN PHASE NOTES Design Phase Activities are referred to as Systems Analysis & Design) Some models say the design phase starts with the creation of the Project Team, or the Organization of the Project Team. Our model classifies those functions as Preparation activities, thus limiting the Design Phase to the true design activities. Definition of User Needs This typically uses personal interviews with management, employees and other stakeholders The SDLC Project Team must differentiate between user needs and user wants. The correct approach is to identify To WHAT USE will the information be put? e.g., identify the decisions to be made, the work to be done with the information. Then determine what information is required to facilitate business activities and decisions of the user. In addition to defining (1) the information requirements, the team must also determine (2) the formatting and presentation requirements, (3) the data capture requirements (including formatting), (4) compliance requirements, and (5) assurance requirements (what operational controls must the system provide?)
Note: this provides an opportunity to re-engineer the business, if within the scope of the project. In addition to five dimensions of the user requirements, the SDLC team needs to consider ergonomic issues. Identification of Data Elements From the identification of the information needed by the user, identify exactly what data elements are used to provide that information. Note that we break information down into data elements. Note that some elements are captured from business activities. Other data elements are calculated or derived. Identify which data elements are captured and from where, how to derive or calculate each element. Creation of Input/Output Specifications After identifying the capture location, determine the input method. Analyze the business process which is creating the data values. Analyze the method of input for efficiency and effectiveness Determine the final form the information should take. Arithmetic calculations necessary? Mathematical calculations necessary? Layouts, presentation, formatting? Prototype the input and output processes Prototype: a pseudo-working model, used to communicate the operation of the finished input/output process. Provides valuable feedback from the end users about the efficiency of the input/output, and its effectiveness. The user can provide valuable suggestions on modifications necessary for convenience, user acceptance, ergonomic factors, etc. Determine the Data Flows Flowcharts illustrate the user business processess. Flowcharts concentrate on document flow. Data element flow is not well illustrated on flowcharts. For this reason, technical specialists use Data Flow Diagrams instead of flowcharts. DFD s more precisely pinpoint the movement of data elements. Develop the Database Architecture and Design This is the job of technical specialists: Data architects, database designers, etc. Three steps: Initial organization of data elements into logical units (records, files, etc.) Data Normalization (to eliminate redundancies) Development of the Data Dictionary and Database structure/schema Creation of Processing Specifications The last phase of the design phase developed the data dictionary. All data elements have been identified, defined, and grouped (organized) into files. Additionally, the prototyping of the input and output processes designed the layout and operation of the data capture, and formatting and presentation functions. Thus, the task at hand now is to actually figure out how to tell the computer to capture that data, produce those reports, and process the captured data into information. This step in the SDLC (creation of processing specifications) determines exactly what each program or app within the system is to do.
Some models place the creation of processing specifications as the last phase in the Design Phase. Some consider them the first step of the Development Phase. Categorization is not as important as understanding what they are and the role they play in the development process. DEVELOPMENT PHASE NOTES Development of the Test Bed The test bed is composed of two parts: Test Data and Test Scripts. Test scripts are the checklist itemizing exactly what should be tested to make sure each and every program is programmed correctly, is designed properly, and works with other programs to provide a usable system. The yardstick used for this purpose is the Processing Specifications. Does the program do what the specifications call for? Test data is the data used for testing the programs to ensure they are programmed correctly and work together to get the job done properly. Testing must not only make sure the system works, it must also ensure that the system does not not work. Negative testing makes sure that the system catches errors, mistakes, and other anomalies. Thus, the testing must include bad data as well as good data. It must check to ensure that when mistakes are executed, the system catches the mistake. This is called negative testing. Negative testing must answer the questions: Does the system catch errors? Can the system be broken? Can the system controls by bypassed? Does the system fail gracefully? Can the system recover from failures? Negative testing includes testing of the Error traps, and the Edit Checks and Validation Checks Edit checks: comparing the input value against criteria to ensure the value falls within acceptable limits Validation checks: comparing the input value against a table or list of acceptable values Good test bed creation should be done in conjunction with the creation of the program specifications. The test bed must be carefully designed so that the testing regimen can: Make sure each program works correctly Make sure each program is accomplishing its purpose Make sure each program works with its surrounding programs Make sure the entire system works together correctly Make sure the system can function properly under full load/capacity Make sure the users can run the business with the system Well-designed systems may even have dedicated programs or routines to routinely go through data stored in the database looking for problems, orphaned data, bad data, errors, etc. Coding (writing of the actual computer programs) After creating the specifications, the programs are written by programmers and developers. Programmers write source code: readable by humans, writable by humans. CASE: Computer-Assisted Software Engineering CASE tools let the computer write source code based on specifications Macro recorders also write source code for humans Computers, however, only execute machine language, e.g., zeroes and ones.
Machine language can be generated one of two ways: Interpreted languages: source code is interpreted at run time into machine language and executed line by line. Compiled language: source code is compiled into object code as part of the development phase. Object code is machine language. A separate video explains the differences between interpreted and compiled languages Important: What are the major security differences between compiled and interpreted languages? Interpreted languages and compiled languages can be either Procedural, or Object Oriented. Typically, Procedural anguages are written by human programmers, line by line. Typically, Object Oriented languages are created using CASE tools. Such CASE tools are exemplified by: macro recorders, web page design software, Access database query/report/screen design tools, and other tools where the programmer uses a pagelayout design application, and then the tool turns it into source code. Testing Regimens The six Testing Regimens correspond to the six objectives of the test bed: Debugging: Does the program work correctlly? Alpha Testing: Does the program accomplish its purpose? Module Testing: Does the program work with its related programs? Integrative Testing: Do the modules integrate together to accomplish the system goals? Volume Testing: Does the system work under full load and at full capacity? Beta Testing: Can the user run the business with the system? Different testing regimens involve different individuals on the project team. Beta testing involves users not on the project team! Watch out for Scope Creep during end-user testing! Version Control keeps track of where each program is within the coding and testing steps. It prevents a program from being tested twice, or not being tested at all, and ensures that a program is re-tested from the beginning of the regimen after every update or change. The Development Phase ends with User Signoff. Often this is a formality for in-house SDLC projects, but is critical for purchased or customized software as it establishes transfer of ownership and creation of obligations on the parties. In effect, user-signoff is the FOB Point for SDLC purchases! IMPLEMENTATION PHASE NOTES Implementation begins right after User Signoff. Installation of the Software on the Production Platform Review the difference between Development Platform and Production Platform. Installation must include re-testing! User Training This can often start well before the software is completed. Often, user training starts during Beta Testing.
Loading of the Real (Live) Data or Conversion of data from old to new system Also needs to be tested. Cutover (Going Live) Approaches Modular Parallel Cold Turkey, Drop Dead, Big Bang, etc. Shakedown Cruise This is not debugging! This is making minor adjustments, tweaks, and polish. Transition to Maintenance Phase Emphasize the Difference between Routine Support and Changes/Modifications/Fixes DOCUMENTATION NOTES Documentation should have been ongoing throughout the project. Documentation should include: Project Administrative History User Contributions (interviews, comments, requests, reasons/rationales, approvals, etc.) Data Dictionary Development History Program Specifications, Program source code, compilation history, Testing History, Change History, Version Control records EVALUATION PHASE NOTES Debriefing at the end of the Shakedown Cruise is critical to help future projects avoid making the same mistakes Complete review at the end of the first year, etc. after implementation is highly recommended, but often is deliberately forgotten or overlooked. Why? End of the Life Cycle? Only upon replacement.