Chapter 2 SSADM Methodology, Basic Principles of SSADM and Automated Systems

1. Chapter 2SSADM Methodology, Basic Principles of SSADM and Automated Systems Prepared by: Miss SharifahRabeahSyedTaha COM 3033

2. Learning Outcome • SSADM Methodology • Basic Principles of SSADM • Automated Systems COM 3033

3. What Is a Methodology? • A formalized approach or series of steps • A set of sequential stages • Each stage has methods, tools, techniques and techniques associated with it • A specification of how systems will be developed • Writing code without a well-thought-out system request may work for small programs, but rarely works for large ones. • There are many different methodologies COM 3033

4. Who Uses Methodologies? • Most Organizations and Firms Today • IBM, Microsoft, Monsanto, NASA, AT&T, Drury Hotels, Edward Jones, A.B. • Majority of Organizations and Firms use a specific type of methodology that is tailored to their needs.

5. What Are Methodologies Used For? • Systems Development • Guidelines or References • Step by Step process • Leads to final product • Analysis • Information • Gathered and Used to help the development process

6. History of Methodologies • Computer-based Info Systems began in the 1950’s. • 1980’s introduced microcomputers • CASE tools development • System developers went from builders to integrators. • 1990’s brought systems integration. • Visual programming environments. • 1990’s brought systems integration. • Visual programming environments. • Present day Info Systems • Internet, Intranet, and Extranets.

7. Popular Methodologies • The Waterfall Methodology • The SDLC Methodology • The RAD Methodology • Phased development • A series of versions • Prototyping • System prototyping • Throw-away prototyping • Design prototyping • Agile Methodologies • eXtreme Programming (XP) • Object-Oriented Methodologies • Rational Unified Process (RUP)

8. Waterfall Methodology

9. Waterfall Methodology • Overview • Introduced by W.W. Royce in 1970 • It was later redesigned using a more iterative process, unfortunately this way was ignored resulting in the current Waterfall methodology • Most System Analysts do not like the Waterfall Method • Each phase must be completed perfectly • There is no overlap or moving backward in phases

10. Waterfall Methodology • Phases • Requirements: The requirements of the system are collected and set in stone. • Design: A blueprint is made for the programmers using the previously collected requirements. • Implementation: System components are designed by coders and integrated together.

11. Testing: After integration the system is tested and bugs are removed. • Installation & Maintenance: The final installation of the system is done at this phase. Users are trained and the system is maintained by the system designers. COM 3033

12. Waterfall Methodology • Pros • Time spent early in production can save a company hundreds of thousands of dollars. • More emphasis is placed on documentation than any other methods.

13. Cons • Impossible to know exactly what is needed in each phase of the software process before some time is spent in the phase following it. • Requirements are locked in too early leaving no room for user feedback and modification. • Too much emphasis on deadlines rather than user requirements. COM 3033

14. Systems Development Life Cycle (SDLC)

15. Systems Development Life Cycle (SDLC) • Overview • Traditional Methodology • Used to develop, maintain, and replace info systems • Common method for systems development • Contains several phases • Planning, Analysis, Design, Implementation, Maintenance.

16. Systems Development Life Cycle (SDLC) • Phases • Planning • Identification phase • Needs are examined as a whole • Analysis • Studies current procedures and Info Systems • Sub phase - Requirement determination • Design • Convert alternative solutions • Inputs and Outputs • Reports, databases, computer processes

17. Implementation • System and Written specs turned over to programmers • Implementation process • Coding, testing, installation • Maintenance • Systems are in operation • Specific problems or changes are made COM 3033

18. Rapid Application Development(RAD)

19. Rapid Application Development(RAD) • Overview • Methodology used to decrease time in development process. • Efficient and Cheaper • Allows systems developers and end users work together from the beginning. • Becoming a more legitimate way of developing Web Based systems. • E-business applications • VisualAge Generator, Java, WebSphere Stuido etc.

20. Rapid Application Development(RAD) • Phases • RAD phases are similar to SDLC • Shortened and Combined – simplifies the development process. • Systems are analyzed in isolation to other systems. • Eliminates time consuming activities. • Coordinating with existing standards and systems during the Design and Development phases • RAD focuses on Prototyping similar to JAD • Prototyping becomes the basis for the new system

21. Phased development A series of versions developed sequentially Prototyping System prototyping Throw-away prototyping Design prototyping Agile Methodologies Extreme Programming RAD Categories

22. Phased Development Methodology Insert Figure 1-4 here

23. Pros and Cons of Phased Development Methodology Pros Cons Users Get a System To Use Quickly Users Work with a System that is Intentionally Incomplete Users Can Identify Additional Needs For Later Versions

24. What is Prototyping? • ’Prototyping’ is the process of quickly building a model of the final software system, which is used primarily as a communication tool to assess and meet the information needs of the user. • Prototyping is the use of approximately 30% of the ultimate staff to build one or two working versions of various aspects of a system. It is not production code but it may eventually become pre-production code or it may be completely discarded. In the prototyping effort, we are not concerned with the maintainability of the code nor are we concerned with formally documenting it COM 3033

25. How Prototyping Works

26. Pros and Cons of Prototyping Methodology Pros Cons Users Interact with Prototype Very Quickly Tendency to do Superficial Analysis Users Can Identify Needed Changes And Refine Real Requirements Initial Design Decisions May Be Poor

27. Throwaway Prototyping

28. Pros and Cons of Throwaway Prototyping Methodology Pros Cons May Take Longer Than Prototyping Risks are Minimized Important Issues are Understood Before the Real System is Built

29. eXtreme Programming (XP) • Overview • An Agile Methodology invented about 8 years ago by Kent Beck • Successful because it stresses customer satisfaction and software creation on demand • Responsive to changing customer requirements even late in the life cycle • Improves software projects in four essential ways; communication, simplicity, feedback, and courage.

30. eXtreme Programming (XP) • Phases • Planning: User stories are collected from the customer. Feedback is given to the customer to help better understand the requirements. • Designing: Primary focus is on keeping the design simple. Constant communication with the customer is used to design and redesign over and over again until they have reached an acceptable solution.

31. Coding: Very iterative process usually done with teams of 2 programmers at a time. Customer feedback is constantly used during the coding process. • Testing: Consistently done after each portion of code is created. If bugs are found the code is reworked and retested. • Releases: These are usually done in small portions. Final product is then thoroughly tested upon release. COM 3033

32. Agile Development: Extreme Programming

33. Pros and Cons of Agile Methodologies Pros Cons Fast Delivery of Results Requires Discipline Works Best in Small Projects Works Well in Projects With Undefined or Changing Requirements Requires Much User Input

34. Rational Unified Process (RUP) • Overview • An Object-Oriented iterative software development process created by the Rational Software Corporation (a division of IBM since 2003) around 1998. • RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development.

35. Rational Unified Process (RUP) Simple Diagram

36. Rational Unified Process (RUP) Detailed Diagram

37. Principles of RUP • The RUP uses six key principles in its development process. • Adapt the process: Decide on the right size project and budget for the organization. • Balance stakeholder priorities: Determines business goals and stakeholder needs. • Collaborate across teams: With a broad variety of stakeholders, all voices need to be heard. Everyone within the project shares information, opinions, and ideas. COM 3033

38. Demonstrate value iteratively: Projects are delivered in an incremental and iterative fashion. This encourages feedback from stakeholders and allows projects to adjust to changing requirements. • Elevate the level of abstraction: Motivates the reuse of software or Framework already created. • Focus continuously on quality: Encourages quality checks through testing not only at the end but during the creation of the projects. COM 3033

39. Rational Unified Process (RUP) • Phases • Inception: Analysts define the scope, determine the feasibility of the project, understand user requirements, and prepare a software development plan. • Elaboration: Analysts detail user requirements and develop a baseline architecture. In this phase an executable demonstration of the critical pieces will be developed.

40. Construction: The software is actually coded, tested, and documented. At the end of this phase a beta version of the project is released that should have operational capabilities. • Transition: The system is deployed, problems are corrected, and the users are trained and supported. Once acceptable criteria are met the product can then be scheduled for final release. COM 3033

41. Rational Unified Process (RUP) • Pros • Establishes a better understanding and communication channel between business engineering and software engineering. • Provides pre-configured process templates for small, medium and large projects, which can be used for easier adoption. • Allows for constant feedback from the business as well as the stakeholders. • Encourages the use of reusable assets such as software pattern, 4GL or Framework which in turn prevents software engineers from having to custom make software.

42. Cons • If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. • Requires an RUP process expert. • May not be applicable to all situations. COM 3033

43. Selecting the Appropriate Methodology • Clarity of User Requirements • Familiarity with Technology • System Complexity • System Reliability • Short Time Schedules • Schedule Visibility

44. Criteria for Selecting a Methodology

45. Basic principles of SSADM SSADM is a data-driven method that there is a basic assumption when employing this methodology. It assumes that a system has an underlying and generic data structure which changes very little over time, although processing requirements may change. This underlying data structure is modeled from an early stage. The representation of this data structure is checked against the processing and reporting requirements and finally built into the architecture of a system. COM 3033

46. Automated Tools for System Development • Computer-aided Software Engineering(CASE) • Automated software tool used by systems analysts to develop information systems • Used to support or automate activities throughout the systems development life cycle (SDLC) • Increase productivity • Improve overall quality of systems COM 3033

47. Objectives of CASE • Improve quality of systems developed • Increase speed of development and design • Ease and improve testing process through automated checking • Improve integration of development activities via common methodologies • Improve quality and completeness of documentation • Help standardize the development process • Improve project management • Simply program maintenance • Promote reusability • Improve software portability COM 3033

48. CASE and System Quality • Majority of organizations adopt CASE to improve speed and quality of systems development projects • Widespread deployment has been slower than expected • Several factors that inhibit widespread deployment • Cost • Between $5,000 and $15,000 per year to provide CASE tools to one systems analyst • Return on Investment • Biggest benefits of CASE come in late stages of SDLC • Productivity Bottlenecks • Inability of some tools to share information • Difficulty in providing tools for all stages of SDLC COM 3033

49. Components of CASE • Types of CASE tools • Diagramming tools • Computer display and report generators • Analysis tools used to check for incomplete, inconsistent or incorrect specifications • A central repository • Documentation generators • Code generators • Security Features • Version Control • Import/Export • Backup and Recovery COM 3033

50. CASE versus TraditionalSystems Development • Traditional approach does not offer support for integration of specification documents • Often, documentation is done after coding is completed in traditional systems development • Traditional approach often leads to out of-date documentation COM 3033