1. Asst.Prof. Dr. Surasak Mungsing

3. 3 Learning Objectives Explain the purpose and various phases of the systems development life cycle (SDLC) Explain when to use an adaptive approach to the SDLC in place of a more predictive traditional SDLC Explain the differences between a model, a tool, a technique, and a methodology Describe the two overall approaches used to develop information systems: the traditional method and the object-oriented method

4. 4 The Systems Development Lifecycle (SDLC) Systems development life cycle (SDLC) Provides overall framework for managing systems development process Two main approaches to SDLC Predictive approach – assumes project can be planned out in advance Adaptive approach – more flexible, assumes project cannot be planned out in advance All projects use some variation of SDLC

5. 5 Traditional Predictive Approach to the SDLC Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project Analysis – understand business needs and processing requirements Design – define solution system based on requirements and analysis decisions Implementation – construct, test, train users, and install new system Support – keep system running and improve

6. 6 “Waterfall” Approach to the SDLC

7. 7 Modified Waterfall Approach with Overlapping Phases

8. 8 Newer Adaptive Approaches to the SDLC Based on spiral model Project cycles through development activities over and over until project is complete Prototype created by end of each cycle Focuses on mitigating risk Iteration – Work activities are repeated Each iteration refines previous result Approach assumes no one gets it right the first time There are a series of mini projects for each iteration

9. 9 Activities of Planning Phase of SDLC Define business problem and scope Produce detailed project schedule Confirm project feasibility Economic, organizational, technical, resource, and schedule Staff the project (resource management) Launch project  official announcement

10. 10 Activities of Analysis Phase of SDLC Gather information to learn problem domain Define system requirements Build prototypes for discovery of requirements Prioritize requirements Generate and evaluate alternatives Review recommendations with management

11. 11 Activities of Design Phase of SDLC Design and integrate the network Design the application architecture Design the user interfaces Design the system interfaces Design and integrate the database Prototype for design details Design and integrate system controls

12. 12 Activities of Implementation Phase of SDLC Construct software components Verify and test Convert data Train users and document the system Install the system

13. 13 Activities of Support Phase of SDLC Maintain system Small patches, repairs, and updates Enhance system Small upgrades or enhancements to expand system capabilities Larger enhancements may require separate development project Support users Help desk and/or support team

14. 14 Methodologies and Models Methodologies Comprehensive guidelines to follow for completing every SDLC activity Collection of models, tools, and techniques Models Representation of an important aspect of real world, but not same as real thing Abstraction used to separate out aspect Diagrams and charts Project planning and budgeting aids

15. 15 Tools and Techniques Tools Software support that helps create models or other required project components Range from simple drawing programs to complex CASE tools to project management software Techniques Collection of guidelines that help analysts complete a system development activity or task Can be step-by-step instructions or just general advice

16. 16 Two Approaches to System Development Traditional approach Also called structured system development Structured analysis and design technique (SADT) Includes information engineering (IE) Object-oriented approach Also called OOA, OOD, and OOP Views information system as collection of interacting objects that work together to accomplish tasks

17. 17 Object-Oriented Approach Completely different approach to information systems Views information system as collection of interacting objects that work together to accomplish tasks Objects – things in computer system that can respond to messages Conceptually, no processes, programs, data entities, or files are defined – just objects OO languages: Java, C++, C#.NET, VB.NET

18. 18 Object-Oriented Approach Object-oriented analysis (OOA) Defines types of objects users deal with Shows use cases are required to complete tasks Object-oriented design (OOD) Defines object types needed to communicate with people and devices in system Shows how objects interact to complete tasks Refines each type of object for implementation with specific language of environment Object-oriented programming (OOP) Writing statements in programming language to define what each type of object does

19. 19 Life Cycles with Different Names for Phases

20. 20 Current Trends in Development The Unified Process (UP): Reinforces six best practices(develop iteratively, define and manage system requirements, use component architectures, create visual models, verify quality, control changes) Extreme Programming (XP): Recent development approach to keep process simple and efficient Agile Modeling: Hybrid of XP and UP Scrum: Respond to situation as rapidly as possible

21. 21 Tools to Support System Development Computer-aided system engineering (CASE) Automated tools to improve the speed and quality of system development work Contains database of information about system called repository Upper CASE – support for analysis and design Lower CASE – support for implementation ICASE – integrated CASE tools Now called visual modeling tools, integrated application development tools, and round-trip engineering tools

22. Q&A

23. © Bennett, McRobb and Farmer 2005 23 Why Analyse Requirements? Use case model alone is not enough Use case model alone is not enough There may be repetition Some parts may already exist as standard components Analysis aims to identify: Analysis aims to identify: Common elements Pre-existing elements Interaction between different requirements

24. © Bennett, McRobb and Farmer 2005 24 What a Requirements Model Must Do A requirements model meets two main needs: Confirms what users want a new system to do Confirms what users want a new system to do Must be understandable for users Must be correct and complete Specifies what designers must design Specifies what designers must design Must be unambiguous

25. © Bennett, McRobb and Farmer 2005 25 What a Requirements Model Must Do Describes what the software should do Represents people, things and concepts important to understand what is going on Shows connections and interactions among these people, things and concepts Shows the business situation in enough detail to evaluate possible designs Is organized so as to be useful for designing the software

26. © Bennett, McRobb and Farmer 2005 26 How We Model the Analysis The main tool used for analysing requirements is the class diagram Two main ways to produce this: Directly based on knowledge of the application domain (a Domain Model) By producing a separate class diagram for each use case, then assembling them into a single model (an Analysis Class Model)

27. © Bennett, McRobb and Farmer 2005 27 Class Diagram: Stereotypes Analysis class stereotypes differentiate the roles objects can play: Boundary objects model interaction between the system and actors (and other systems) Entity objects represent information and behaviour in the application domain Control objects co-ordinate and control other objects

28. © Bennett, McRobb and Farmer 2005 28 Class Diagram: Stereotypes

29. © Bennett, McRobb and Farmer 2005 29 Class Diagram: Stereotypes

30. © Bennett, McRobb and Farmer 2005 30 Class Diagram: Stereotypes

31. © Bennett, McRobb and Farmer 2005 31 Class Diagram: Class Symbol

32. Class Diagram: Instance Symbol

33. © Bennett, McRobb and Farmer 2005 33 Class Diagram: Attributes Attributes are: Part of the essential description of a class The common structure of what the class can ‘know’ Each object has its own value for each attribute in its class

34. Class Diagram: Links

35. © Bennett, McRobb and Farmer 2005 35 Class Diagram: Associations Associations represent: The possibility of a logical relationship or connection between objects of one class and objects of another If two objects can be linked, their classes have an association

36. © Bennett, McRobb and Farmer 2005 36 Class Diagram: Associations

37. © Bennett, McRobb and Farmer 2005 37 Class Diagram: Multiplicity

38. © Bennett, McRobb and Farmer 2005 38 Class Diagram: Operations Operations describe what instances of a class can do: Set or reveal attribute values Perform calculations Send messages to other objects Create or destroy links

39. © Bennett, McRobb and Farmer 2005 39 From Requirements to Classes Start with one use case Identify the likely classes involved (the use case collaboration) Draw a collaboration diagram that fulfils the needs of the use case Translate this collaboration into a class diagram Repeat for other use cases

40. From Requirements to Classes

41. Sequence Diagrams Oct-1541

42. 42 :Client :Campaign :Advert getName listCampaigns ref :CampaignManager alt [else] sd Add a new advert to a campaign if within budget List client campaigns [totalCost <= budget] ref Create advert Create request ref Get campaign budget addCostedAdvert

43. Interaction Fragment Used :Campaign :Advert getCost sd Get campaign budget loop getOverheads checkCampaignBudget :CampaignManager [For all campaign’s adverts]

44. Simple activity diagram Link to CreativeStaff Create new StaffGrade Link to previous StaffGrade Set previous StaffGrade gradeFinishDate An activity diagram show the main steps for the operation

45. Activity Diagram with Selection and Iteration Calculate bonus [bonus > £250] Add to list [more StaffMembers] Format list [no more StaffMembers] Add to ‘star’ list Create warning letter [bonus < £25] [bonus >= £25 AND bonus <= £250]

46. © Bennett, McRobb and Farmer 2005 46 System Design and Detailed Design System design deals with the high level architecture of the system structure of sub-systems distribution of sub-systems on processors communication between sub-systems standards for screens, reports, help etc. job design for the people who will use the system

47. © Bennett, McRobb and Farmer 2005 47 System Design and Detailed Design Object-oriented detailed design adds detail to the analysis model types of attributes operation signatures assigning responsibilities as operations additional classes to handle user interface additional classes to handle data management design of reusable components assigning classes to packages

48. © Bennett, McRobb and Farmer 2005 48 Qualities of Analysis Correct scope—everything in the system is required Completeness—everything required is in the system and everything is documented in the models Correct content—accurate description of requirements Consistency—each element is consistently referred to by the same name

49. © Bennett, McRobb and Farmer 2005 49 Qualities of Design Functional—system will perform the functions that it is required to Efficient—the system performs those functions efficiently in terms of time and resources Economical—running costs of system will not be unnecessarily high Reliable—not prone to hardware or software failure, will deliver the functionality when the users want it

50. © Bennett, McRobb and Farmer 2005 50 Qualities of Design Secure—protected against errors, attacks and loss of valuable data Flexible—capable of being adapted to new uses, to run in different countries or to be moved to a different platform General—general-purpose and portable (mainly applies to utility programs) Buildable—Design is not too complex for the developers to be able to implement it

51. © Bennett, McRobb and Farmer 2005 51 Qualities of Design Manageable—easy to estimate work involved and to check of progress Maintainable—design makes it possible for the maintenance programmer to understand the designer’s intention Usable—provides users with a satisfying experience (not a source of dissatisfaction) Reusable—elements of the system can be reused in other systems

52. Q&A

53. http://staruml.en.softonic.com/