Advertisement
Guest User

Untitled

a guest
Jun 19th, 2017
150
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 11.58 KB | None | 0 0
  1. Definitions
  2. Requirements:
  3. what features should be in the system (use cases)
  4. what information should be handled in the system (classes)
  5. what are the requirements for quality (response times, security …)
  6. Design :
  7. how the system is structured overall (architecture)
  8. how should the information be stored (database)
  9. how are the objects created (methods)
  10. how are the user interface going to look
  11. Implementation
  12. Programming and test
  13. Production
  14. Maintenance
  15. System development
  16. Preliminary study
  17.  
  18. The requirements to an IT system can be listed in feature lists:
  19. Functional requirement, e.g.: the system should be able to register information about an order and print out a receipt
  20. Non functional requirement (the quality of the system):
  21. the system must be for novice users
  22.  
  23. Functional requirements are described in use cases.
  24. Information requirements are describes in a domain model.
  25.  
  26. In order to derive the requirements, we start with the asking future users, their tasks and requests for IT support.
  27.  
  28. The purpose is to collect information about:
  29. Current situation – What kind of problems are there?
  30. Desired situation– What should the IT system be able to do?
  31.  
  32. The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language, that is intended to provide a standard way to visualize the design of a system. Mostly used in object oriented development.
  33.  
  34. Mock-up /Prototyping steps
  35. Planning
  36. Purpose and extent of prototype?
  37. Development
  38. Which tool?
  39. Preparation
  40. Roles (user and developer) during testing?
  41. How to do the testing?
  42. How to make the test cases?
  43. Documentation
  44. How to document the testing?
  45. Evaluation
  46.  
  47. System dev. parts
  48.  
  49. Use cases are descriptions of the systems functionality seen from the users point of view (found by doing Preliminary study)
  50. Use case diagram is a graphic model of the system's functionality and communication with the stakeholders.
  51. Three use case description formats:
  52. Brief: textual description of a happy days scenario
  53. Casual: Includes variations of happy days scenario
  54. Fully dressed: Includes variations of happy days scenario and failures
  55.  
  56. A domain model describes information requirements.
  57. Visual representation of conceptual classes or real-world objects in a domain of interest.
  58. A conceptual class e.g. has:
  59. name
  60. attributes (names)
  61.  
  62. A System Sequence Diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events. All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.
  63.  
  64. The operation contract describes in detail what state the domain model is in after the system operation has finished.
  65. In a way the contract ties the functionality (use cases) and the information (domain models) together.
  66.  
  67. Interaction diagram describes interaction between different elements in the model (like classes, objects ...).
  68. 1.Communication diagram (more like design class diagram)
  69. 2.Sequence diagram
  70.  
  71. The design classes to be included in the use case realization is found based on the layered architecture and the domain model.
  72. A design class diagram contains:
  73. Classes and associations, interfaces, methods, attributes incl. data type visibility
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91. A class describes a collection of objects that have similar attributes and behaviors.
  92.  
  93. Object structures:
  94. Association: A relation between some objects. 1 object of a class has relation to 1 or more objects of another class.
  95. Composite aggregation: A whole-part hierarchy. The part only exist if the whole exist. Stronger than association.
  96. Class structures:
  97. Generalization: A hierarchical structure, where the general class (the superclass) has properties, which is common for some specialized classes (subclasses).
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108. As a transition to design we describe the system behavior (what the system does, not how) –by:
  109. system sequence diagram (one particular scenario of a use case)
  110. operation contracts (Give a more precise description of system behavior.)
  111.  
  112.  
  113.  
  114. The layered architecture requires a design class for each layer:
  115. – Interface (UI) classes which handles the interaction between the actor and the interface (UI). Sendder håndterer interaktionen mellem aktøren og grænsefladen. Sends system events on to the controller class.
  116. – Controller classes which gets the responsebilityto ”glue” the interface
  117. and the domain classes together.
  118. – Model classes which are found from the domain model over the problem area. The model classes which support the use cases are include.
  119.  
  120. GRASP-General Responsibility Assignment Software Patterns
  121. GoF- Gang Of Four
  122. grasp patterns:
  123. 1. Creator (a general principle for the assignment of creation responsibilities)
  124. 2. Information Expert (Assign responsibility to an object having the information needed to fulfill the job)
  125. 3. Low coupling (two classes/components have high coupling if changes in one class/component requires changes in the other class/component as well)
  126. 4. Controller (Represents a receiver or handler of all system events of a use case scenario)
  127. 5. High cohesion (keeping parts of a code base that are related to each other in a single
  128. place)
  129. 6. Indirection ()
  130. 7. Polymorphism
  131. 8. Protected Variations
  132. 9. Pure Fabrication
  133. GoF pattern:
  134. 1. Singleton (Only one instance of a class is allowed)
  135.  
  136. Waterfall: A sequentially passes through the activities requirement, design, implementation and test.
  137.  
  138. Unified Process (UP) : The result of each iteration is an executable, but incomplete system, system may need many iterations before it is ready for production. (The complex use cases are done in the first iterations of UP)
  139. 1. Use-case driven
  140. 2. Architecture centric
  141. 3. Iterative and incremental development
  142. 4. Use of UML
  143.  
  144. Gains from UP:
  145. 1. Less project failure
  146. 2. Early mitigation of risks
  147. 3. Early visible progress
  148. 4. Early feedback
  149. 5. User engagement leading to a system that more nearly meets the needs
  150. 6. Managed complexity
  151. 7. Learning from an iteration can be used in later iterations
  152.  
  153. Unified Process phases:
  154. 1. Inception:
  155. Establish the business case for the system, define risks, scope, obtain 10% of the requirements, estimate next phase effort.
  156. 2. Elaboration:
  157. Develop an understanding of the problem domain and the system architecture, risk significant portions may be coded/tested, about 80% of major requirements identified.
  158. 3. Construction:
  159. System design, programming and testing. Building the remaining system in short iterations.
  160. 4. Transition
  161. Deploy the system in its operating environment. Deliver releases for feedback and deployment.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175. Normalization
  176.  
  177. May be used as measures to determine the quality of relation schema design:
  178. 1. Making sure that the semantics of the attributes is clear in the schema
  179. 2. Reducing the redundant information in tuples
  180. 3. Reducing the NULL values in the tuples
  181. 4. Disallowing the possibility of generating spurious tuples
  182.  
  183. Normal forms (NF) provide formal guideline for the design of the tables.
  184. Normalization is the process of decomposing unsatisfactory “bad” relations by breaking up their attributes into smaller relations.
  185.  
  186. Super Key- set of attributes whose values guarantee uniqueness of each row
  187. Candidate Key- a minimal super key (if you remove an attribute it is not any longer a super key)
  188. Primary Key- a designed candidate key
  189. Primary attribute- an attribute of a candidate key
  190.  
  191. Qualifications for 1NF are:
  192. Contains only atomic values; There are no repeating groups
  193. …………………………………………………………………………………………………………
  194. Qualifications for 2NF are:
  195. Second normal form states that it should meet all the rules
  196. for 1NF and there must be no partial dependences of any
  197. of the columns on the primary key
  198. ………………………………………………………………………………………………………..
  199. Qualifications for 3NF are:
  200. is in 2nd NF and all non primary fields are dependent on the primary key
  201.  
  202.  
  203. …………………………………………………………………………………………………………
  204. Qualifications for BCNF are: (Boyce-Codd normal form)
  205. if one field in different table is changed than changes are made to everybody who uses this row. (not original definition probably even wrong)
  206.  
  207. Defining Software Quality: Three Aspects:
  208. 1. Functional quality means that the software correctly performs the tasks it’s intended to do for its users.
  209. 2.Structural quality, means that the code itself is well structured.
  210. 3.The quality of the development process significantly affects the value received by users, development teams, and sponsors.
  211.  
  212. Patterns:
  213. Adapter (bridge between two incompatible interfaces)
  214. Factory (one object responsible for creation for of closely related objects)
  215. Singleton (create one instance of class)
  216. Strategy (behavior or algorithm can be changed at run time depending on neccasity)
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230. Business
  231. SWOT (strengths weaknesses opportunities threats)is useful when defining strategy
  232. PESTEL (when looking to create business in different country) :
  233. Political
  234. Environment
  235. Social
  236. Technological
  237. Legal factors
  238. Economical
  239.  
  240. Porter 5 forces – Industry analysis, shows competitive situation (threat of new entry, competitive rivalry, Buyer power, Threat of substitution, Supplier power)
  241.  
  242. Mission- The fundamental purpose of an enterprise that defines the nature of its business and provides strategic direction to unify the use of human and other resources
  243.  
  244. Vision- A desired future image of the organization and its processes and products that integrates current realities and expected future conditions within a specific time frame
  245.  
  246. The three elements of a vision:
  247. 1. A statement of purpose - the ideology and core values combines a purpose – does not need to be understandable to outsiders but only inspire and motivate insiders
  248. 2. A tangible goal - a clear, specific, and compelling goal should be framed to focus peoples efforts.
  249. 3. An image of results – The image should paint a compelling picture using “crisp” language.
  250.  
  251. The business case defines what is to be done, why, and what are the timescales and costs involved.
  252.  
  253. Stakeholders- a person, group or organization with an interest in a project.
  254.  
  255. ROI (return on investment)- benefit to an investor resulting from an investment of some resource. A high ROI means the investment's gains compare favorably to its cost. As a performance measure, ROI is used to evaluate the efficiency of an investment or to compare the efficiencies of several different investments.
  256.  
  257. organizational structure- An organizational structure defines how activities such as task allocation, coordination and supervision are directed toward the achievement of organizational aims.
  258.  
  259. Stakeholder analysis- impact of a decision on relevant parties.
  260.  
  261. E-business- a term which can be used for any kind of business or commercial transaction that includes sharing information across the Internet.
  262.  
  263. Project- complex, non-routine, one time effort limited by time, budget, resources and performance specifications designed to meet costumer needs.
  264. 1. Defining
  265. 2. Planing
  266. 3. Executing
  267. 4. Delivering
  268.  
  269. Atomic- cannot further divide.
  270.  
  271. Work breakdown (WBD)- approach to consider what has to be done to meet project objectives.
  272.  
  273. Inbound logistics- The management of material resources entering an organization from its suppliers and other partners.
  274. Outbound logistics- The management of resources supplied from an organization to its customers and intermediaries.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement