Lecture 4 : System Analysis and Design Methodologies

1. Lecture 4:System Analysis and Design Methodologies Telematics systems and their design Doc.Ing. Ondřej Přibyl, Ph.D. Department of applied mathematics Faculty of Transportation sciences, CTU

2. Scope of this lecture • Part I - Overview of methodologies • Part II - Recommendation to ITS

3. PART ISystems Development Methodologies

4. Discussion • What does actually mean the term „Methodology“?

5. A methodology is a formalized approach to implementing the SDLC. • The methodology will vary depending on whether the emphasis is on businesses processes or on the data that supports the business. • Remember it has nothing to do with UML!

6. Overview of System Development Methodologies

7. Category I of the System Development Methodology: Structured Design Adopts a formal step-by-step approach to the SDLC that moves logically from one phase to the next. Introduces the use of formal modeling or diagramming techniques to describe a system’s basic business processes and follows a basic approach of two structured design categories.

8. Waterfall Development

9. Waterfall Development • With waterfall development- based methodologies, the analysts and users proceed sequentially from one phase to the next.

10. Waterfall Development • Advantages: • The system requirements are identified long before programming begins. • Changes to the requirements are minimized as the project proceeds. • Disadvantages: • The design must be completely specified before programming begins. • A long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system.

11. Parallel Development This methodology attempts to address the long time interval between the analysis phase and the delivery of the system in case of a waterfall model.

12. Parallel Development

13. Category II of the SystemDevelopment Methodology: Rapid Application Development (RAD) This methodology breaks the overall system into a series of versions that are developed sequentially.

14. Rapid Application Development (RAD) • RAD-based methodologies adjust the SDLC phases to get some part of system developed quickly and into the hands of the users. • A system development strategy that emphasizes speed of development through extensive user involvement in the rapid, iterative, and incremental construction of series of functioning prototypes of a system that eventually evolves into the final system. • One possible subtle problem (disadvantage) with RAD-based methodologies is managing user expectations. • Prototype – a small-scale, representative, or working model of the users’ requirements or a proposed design for an information system. • Time box – the imposition of a nonextendable period of time, usually 60-90 days, by which the first (or next) version of a system must be delivered into operation.

15. Rapid Application Development • focuses on building applications in a very short amount of time; traditionally with compromises in usability, features and/or execution speed. • generically describes applications that can be designed and developed within 60-90 days.

16. Phased Development

17. Phased development • The team categorizes the requirements into a series of versions, then the most important and fundamental requirements are bundled into the first version of the system. • The analysis phase then leads into design and implementation; however, only with the set of requirements identified for version 1. • As each version is completed, the team begins work on a new version.

18. Phased development

19. Prototyping-based Methodology A prototype is a smaller version of the system with a minimal amount of features. Prototyping-based methodologies perform the analysis, design and implementation phases concurrently. All three phases are performed repeatedly in a cycle until the system is completed.

20. Prototyping-based Methodology

21. Prototyping-based Methodology • Advantage: • Provides a system for the users to interact with, even if it is not initially ready for use. • Helps to capture real user requirements • Disadvantage: • Often the prototype undergoes such significant changes that many initial design decisions prove to be poor ones.

22. Throwaway Prototyping-based Methodology

23. Throwaway Prototyping-based Methodology • Throwaway prototyping methodologies are similar to prototyping based methodologies. • The main difference is that throwaway prototyping IS completed during a different point in the SDLC. • Has relatively thorough analysis phase.

24. Throwaway Prototyping-based Methodology • Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final software. • After preliminary requirements gathering, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system. • Advatages • it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. • ability to construct interfaces that the users can test.

25. Category III of the SystemDevelopment Methodology: Agile Development Focuses on streamlining the SDLC by eliminating much of the modeling and documentation overhead and the time spent on those tasks. Projects emphasize simple, iterative application development.

26. Agile Methods • Agile methods have much in common with the Rapid Application Development • Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. • Iterations are short time frames that typically last from one to four weeks. • Each iteration involves a cross functional team working in all functions: • planning, requirements analysis, design, coding, unit testing, and acceptance testing. • At the end of the iteration a working product is demonstrated to stakeholders. • This minimizes overall risk and allows the project to adapt to changes quickly.

27. An Extreme Programming-based Methodology

28. An Extreme Programming-based Methodology • eXtreme Programming (XP) was founded on four core values: • Communication • Simplicity • Feedback • Courage • Key principles of XP include: • Continuous testing • Simple coding • Close interaction with the end users to build systems very quickly • Smaller development teams

29. An Extreme Programming-based Methodology

30. SCRUM (Agile development) Source: www.redletterday.ch

31. Challenges of Agile methods • can be inefficient in large organizations and certain types of projects • Agile methods seem best for developmental and non-sequential projects • Many organizations believe that agile methodologies are too extreme and adopt a hybrid approach that mixes elements of agile and plan-driven approaches • It is all about communication!

32. Selecting the Appropriate Development Methodology

33. Selecting of methodology • Selecting a methodology is not simple, as no one methodology is always best. • Many organizations have their own standards. • The next figure summarizes some important methodology selection criteria.

34. Criteria for Selecting a Methodology

35. As the methodology and project management in IT projects improves, the success rate grows How is it affected by selected methodology? IT Project success Rate (Chaos report)

36. Project success rates Source: Dr. Dobbs IT Survey 2010 http://www.ddj.com/security/226500046

37. Agile projects are 3 times more successful http://www.controlchaos.com/storage/S3D%20First%20Chapter.pdf

38. Effectiveness of development Paradigms

39. PART IIMethodology recommended for ITS SEMP Framework (FHWA for ITS) Methodology to design ITS (CZ)

40. SEMP Framework (http://www.fhwa.dot.gov/cadiv/segb/index.htm)

41. 1. System Engineering Management Plan (SEMP)

42. 1. System Engineering Process – Main features • Based on common Vee development model • Consists of the following major phases: • System decomposition (Step 1 – 5) • System implementation (Step 6) • System composition (Step 7 – 10) • System operation (Step 11) • Unified Modeling Language (UML) is used to cover the steps in the model (concept, requirements design, test cases, etc.) • Defines • Major steps, • Deliverables, and • Responsibilities.

43. 2. Methodology recommended for ITS Systems • Described in “Methodology to design ITS”(CTU, In Czech, 2009) • Based on SSADM (Structured System Analysis and Design Methodology) • Analysis of the current system • Feasibility stage • Outline business specification • Concept preparation • Detailed business specification • Requirements specification stage • Logical data design • In this stage, technically feasible options are described • Logical process design • logical designs and processes are updated • Physical design • to specify the physical data and process design

44. ITS process – an overview Part 1 Part 2 Part 3 Part 4 Part 5

45. System concept Based on ITS architecture Includes current state analysis Includes definition of objectives Define actors See lecture notes Define User needs RFP and other user documents Based on ITS architecture Based on system concept Analysis and Design of ITS Systems (Part 1)

46. System Requirements Specification (SRS) Based on user needs Based on standards Based on state of the art know-how Analysis and Design of ITS Systems (Part 2)

47. Use case diagram Behavior description / processes Textual process / Activity diagram / interaction diagram Analysis and Design of ITS Systems (Part 3)

48. Physical model HW components Interactions among components Communication architecture Interface specification Assignement of functions (use cases) to HW Data model (Structures) ER Model Analysis and Design of ITS Systems (Part 4)

49. Analysis and Design of ITS Systems (Part 5)

50. Summary of major steps and deliverables System concept • Preparing system concept • Requirement analysis • Specify User needs • Define Requirements on the system • Functionality analysis • Define actors in the system • Define use cases and assign them to particular actors • Define exact functionality for each use case • Data model • Creating of an entity-relationship (E-R) model • Definition of all tables and their relationships • Component design/physical design • Major physical components • Assignment of functions (use cases) to physical components • Interface definition Requirements specification Functional architecture Database design Physical architecture