1. 10. System Design System Analysis And Design Program: BSCS II (Advent Semester – 2014) Lecturer: Rebecca Asiimwe Email: rasiimwe@technology.ucu.ac.ug 1

2. Introduction The Design phase of the SDLC uses the requirements that were gathered during analysis to create a blueprint for the future system Purpose of analysis is to figure out business needs Purpose of design is to decide how to build the system Systems design is the process or art of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements

3. Design Phase steps 1.Present design alternatives- Alternative matrix 2.Convert logical process and data model to physical process and data model- process and data models 3.Design the architecture for the system- Architecture design 4.Make hardware and software selection- Hardware/Software specifications 5.Design the inputs and outputs of the system- Interface design

4. 1.Design the way in which data will be stored- Data storage design 2.Design programs that will enable the process of the system- Program design 3.Create the final deliverable for the design phase- system specification: all of the above deliverables are combined and presented to approval committee 4

5. Step 1 Until now we have assumed that the system will be built and implemented by the project team However there are three ways to approach the creation of a new system 1.Developing custom application(in-house) 2.Buying a packaged system and customize 3.Relying on an external vendor, developer or service provider to build the system Each of these has strengths and weakness and is more appropriate in different situations

6. Custom Development  Team has complete control over the system looks and functionality  Good for high specialized requirements  Allows developer to be flexible and creative in a way they solve business problems  It builds technical skills and functional knowledge within the company Long hours of working and dedication Variety of skills have to be in place No guarantee that the project will succeed Delay -technical obstacles

7. Packaged Software For some it makes little sense to reinvent the wheel Some needs can be easily met by packaged software The packages have already been created, tested and proven Can be bought and installed in a relatively short period of time Incorporates the expertise and experience of the vendor who created it –Must accept the function that is provided by the system and rarely is there a perfect fit Most allow customization and manipulation

8. Packaged Software Project teams can introduce a workaround; custom-built-add on program that interfaces with the packaged application to handle special needs. Workarounds are not supported by the Vendor - Incase problem, the vendor blames it on the workaround, hence no support.

9. Outsourcing Require the least amount of in-house resources Means hiring an external vendor, developer or service provider to create the system Has become popular in recent years Used when more in-house experienced programming and technology is required yet not available.

10. Reduces costs Opportunity to add value to the business Compromises confidential information as outsiders are the ones who work on solution using company data Lose control over future development In-house professionals don’t benefit from the skills that could have been learnt 10

11. Outsourcing contract There are three primary types of contracts that can be drawn to control the outsourcing deal –Time and arrangement-Agree to pay for whatever time and expenses that are needed to get the job done –Fixed- price - you pay no more than expected. Incase costs exceed, then the vendor absorbs the costs –Value added – outsourcer/vendor reaps some percentage of the completed system’s benefits Managing outsourcing relationship is a full time job, someone is assigned to manage this

12. Evaluate design strategies When to use Custom Development When to use a Packaged system When to use Outsourcing Business needs The business need is unique The business need is common The Business need is not core to the business In- house experience In- house functional and technical experience exists In-house functional experience exists In-house functional or technical experience doesn’t exists Project Skills There is a desire to build in-house skills The skills are not strategic The decision to outsource is a strategic decision Project Management The project has a highly skilled project manager and a proven Methodology The project has a project manager who can coordinate vendors effort The project has a highly skilled project manager at the level of the organization that matches the scope of the outsourced deal Time frameThe time frame is flexible The time frame is short The time frame is short or flexible

13. Selecting a Design Strategy Alternative matrix can be used to organize the pros and cons of the design alternatives so that best solution will be chosen in the end. It’s a grid with technical, budget, and organizational feasibilities for each system candidate, pros and cons associated with adopting each solution and other information that is helpful when making comparison Challenge is finding the criteria, what helps is the RFP (Request for Proposal) RFP explains the system you are trying to build and the criteria that you will use to select the system

14. 2. Converting logical to Physical Models So far Processes supporting business system have been defined by logical DFDs and ERDs that define the data used by the processes These models do not contain any indication of how the system will be built, they simply state what the new system will do Physical process models and data models are created to show implementation details and explain how the final system will work

15. Logical to Physical model Physical models; –show references to actual technology, –format of information moving through processes –human interaction that is involved.

16. Physical DFDs Contains same components as logical DFDs and same rules apply. They contain additional details that describe how the system will be built The conversion follows five steps –Add implementation reference –Draw a human-machine boundary –Add system-related data stores, data flows and processes –Update the data elements in the data flows –Update the metadata

17. Physical DFDs StepExplanation Add implementation referencesUsing existing logical DFD, place the way in which the data stores, data flows and processes will be implemented in parenthesis below each component Draw a human- machine boundaryDraw a line to separate the automated parts of the system from manual parts Add system-related data stores, data flows and processes Add these components to the model Update the data elements in the data flow Update to include system-related data elements Update the metadata update to include physical characteristics

18. Physical ERD StepsExplanation Change entities to tables or files Make changes to entities, to tables to files and update metadata Change attributes to fieldsConvert attributes to fields and update metadata Add Primary keyAssign primary key to all entities Add Foreign keyAdd foreign keys to represent relationships among entities Add system-related components Add system-related tables and fields

19. Use Case Analysis 19

20. Objectives Understand the role of Use cases Understand the process used to create Use cases Be able to create Use cases

21. Use cases Describe in more details the key elements of the requirement definition Explain the process by which the system will meet the functional requirements Use Cases are the main tasks performed by the users of the system. –Use Cases describe the behavioral aspects of the system. –They are used to identify how the system will be used. –They are a convenient way to document the functions that the system must support. –Use Cases are used to identify the components (classes) of the system.

22. 22 A use case is an activity a system carries out, usually in response to a user request A use case is an external view of the system that represents some action the user might perform in order to complete a task. A Use Case is functionality provided by the system, typically described as verb + object (eg. Register Car, Delete User). Use Cases are depicted with an ellipse (circle) Use Case Definition

23. Use Case Principles Describes required functionality in terms of the user – system Identifies external actors Identifies system boundary Describes scenarios of use Describes pre/post conditions Describes variants/exceptions

24. 24 Use Case diagram Components 1.Use cases 2.Actor 3.Association

25. Use Case Notation (Basic) Use Case Actor Association System Boundary (often implied)

26. 26 Actors An actor is a person, organization, or external system that interacts with the system. Actors are drawn as stick figures. Customer

27. 27 Association Associations are used to link Actors with Use Cases, and indicate that an Actor participates in the Use Case in some form. Associations are depicted by a line connecting the Actor and the Use Case.

28. Use Case (Basic) Example Customer Financial Institution Credit Card System Perform Card Transaction Retail Institution Process Customer Bill Manage Account

29. 29 Use Case usage 1.Describes the behavior of a system from a user's standpoint. Providing a high-level view of what the system does. 2.Provides functional description of a system and its major processes. 3.Provides graphic description of the users of a system and what kinds of interactions to expect within that system. 4.Identifying the users ("actors") of the system.

30. Building Use case 1. Identify all of the actors who will use the system. 2. Interview these actors to identify the functions that they need to perform. (use cases) 3. Identify scenarios (sequence of steps to accomplish a use case). 4. Identify common steps within the different scenarios. Separate them into different use cases so that they can easily be included in other scenarios. 5. Identify relationships between use cases.

31. 31 One of the goals during analysis is to identify potential opportunities for reuse, a goal you can work toward as you are developing your use-case model. Potential reuse can be modeled through four generalization relationships supported by UML use-case models : 1 - Extend dependencies between use case. 2 - Include dependencies between use case. 3 - Inheritance between use case. 4 - Inheritance between actors. Reuse in Use-Case Model

32. 32 The extends association is used when you have one use case that is similar to another use case but does a bit more or is more specialized; in essence, it is like a subclass Include relationship is a situation in which one use case requires the services of a common subroutine. Inheritance between actors means that one actor fills the same roles as another actor. It may also fill additional roles. It interacts with the same use cases in the same way, indicated by a generalization relationship.

33. 33 > Relationship > Relationship Documents situation in which one use case requires the services of a common subroutine A common use case can be reused by multiple use cases E.g., two use cases “Create new order” and “Update order” may need to validate the customer account as shown in the use case diagram in the following slide.

34. 34 Example of Order-Entry Subsystem with > Use Cases

36. 36 Airline reservation system

37. Architecture Design 37

38. Overview Architecture design is very important because it describes the systems hardware, software and network environment of the to-be system. It flows from nonfunctional requirements; operational, performance, security, cultural and political environment Deliverable is the architecture design and hardware and software specifications 38

39. Key Definitions Architecture design –Plans for how the system will be distributed across computers and what hardware and software will be used for each computer (objective is to determine what part of application software will be assigned to what hardware) Hardware and software specification –Describes the hardware/software components in detail to aid those responsible for purchasing those products. 39

40. ELEMENTS OF AN ARCHITECTURE DESIGN 40

41. Architectural Components of Software Data storage- –Most ISs require data to be stored and retrieved Data access logic- –Processing required to access stored data( database queries) Application logic –Processing logic of the application (as depicted by DFDs, use cases and functional requirements) Presentation logic –Information display and user command processing 41

42. Architectural Hardware components Client computers Input/output devices employed by users PCs, laptops, handheld devices, cell phones Server Computers Larger computers storing software and hardware that can be accessed by anyone with permission Mainframes, minicomputers, microcomputers Network Connects computers, vary in speed (there are slow, medium, fast and high speed networks) 42

43. IS Architecture Choices Server-based Architecture Client-based Architecture Client-server based Architecture 43

44. Server-Based Architecture 44

45. Client-Based Architecture 45

46. Client-Server Architecture (Two-Tiered) 46

47. Client-Server Attributes Benefits –Scalable –Works with multiple vendors/products through middleware –Improved modularity of web-based systems –No central point of failure Limitations –Complexity –New programming languages and techniques (adds stress for personnel) –More complex to update 47

48. Three-Tiered Client-Server Architecture 48

49. Four-Tiered Client-Server Architecture 49

50. N-Tiered versus 2-Tiered Client-Server Architectures Benefits –Separates processing to better balance load on different servers –More scalable Limitations –Greater load on the network –More difficult to program and test 50

51. CREATING AN ARCHITECTURE DESIGN 51

52. Selecting an Architecture Design Lower costs are often used to justify choice of client-server Recommended selection process: –Expand nonfunctional requirement details –Base architecture selection on the detailed nonfunctional requirements 52

53. Operational Requirements RequirementDefinitionExample Technical Environment Special hardware, software, and network requirements imposed by business requirements Always-on network connection permitting real-time database updates System Integration The extent to which the system will operate with other systems The system will read and write to the main inventory database Portability The extent to which the system will need to operate in other environments The system may need to operate with handheld devices Maintainability Expected business changes to which the system should be able to adapt The system must accommodate new manufacturing plants

54. Performance Requirements RequirementDefinitionExample Speed Time within which the system must perform its function Network transaction response time <= 7 seconds Capacity Total and peak number of users and the volume of data expected Maximum of 100-200 simultaneous users at peak times Availability and Reliability Extent to which the system will be available to the users and the permissible failure rate due to errors 99% uptime performance

55. Security Requirements RequirementDefinitionExample System Value Estimates Estimated business value of the system and its data A complete loss of all system data would cost $20 million Access Control Limitations on who can access what data Inventory changes can be made only by department managers Encryption and Authentication Defines what data will be encrypted where and whether authentication will be needed for user access Data will be encrypted from the user’s computer to the Web site to provide secure ordering Virus Control Controls to limit virusesAll uploaded files will be checked for viruses before being saved in the system

56. Cultural/Political Requirements RequirementDefinitionExample Multilingual The language(s) the system users will need The system will operate in English, French, and Spanish Customization Specification of what aspects of the system can be changed by local users Country managers will be able to define new fields in the product database to capture country-specific information Making Unstated Norms Explicit Explicitly stating assumptions that differ from country to country All weights will be stated in kilograms Legal The laws and regulations that impose system requirements Personal customer information cannot be transferred from European Union countries to US

57. Designing the Architecture Technical environment requirements driven by business requirements, often define the application architecture If not, other nonfunctional requirements become important 57

58. Nonfunctional Requirements and the Architecture Design

59. 59

60. HARDWARE AND SOFTWARE SPECIFICATION 60

61. Hardware and Software Specification Used if new hardware or software must be purchased Communicates project needs Actual acquisition of hardware and software usually left to a purchasing department -- especially in larger firms 61

62. Hardware and Software Specification Determine software needs –OS, special purpose –Training, warranty, maintenance, licensing needs Determine hardware needs –Server(s), clients, peripherals, backup devices, storage components –Minimum configuration needs 62

63. Summary The three fundamental computing architectures are server-based, client- based, and client-server based. Select architecture design based on detailed nonfunctional requirements Hardware and software specification documents acquisition needs 63

64. Q & A 64