Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Definitions
- Requirements:
- what features should be in the system (use cases)
- what information should be handled in the system (classes)
- what are the requirements for quality (response times, security …)
- Design :
- how the system is structured overall (architecture)
- how should the information be stored (database)
- how are the objects created (methods)
- how are the user interface going to look
- Implementation
- Programming and test
- Production
- Maintenance
- System development
- Preliminary study
- The requirements to an IT system can be listed in feature lists:
- Functional requirement, e.g.: the system should be able to register information about an order and print out a receipt
- Non functional requirement (the quality of the system):
- the system must be for novice users
- Functional requirements are described in use cases.
- Information requirements are describes in a domain model.
- In order to derive the requirements, we start with the asking future users, their tasks and requests for IT support.
- The purpose is to collect information about:
- Current situation – What kind of problems are there?
- Desired situation– What should the IT system be able to do?
- 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.
- Mock-up /Prototyping steps
- Planning
- Purpose and extent of prototype?
- Development
- Which tool?
- Preparation
- Roles (user and developer) during testing?
- How to do the testing?
- How to make the test cases?
- Documentation
- How to document the testing?
- Evaluation
- System dev. parts
- Use cases are descriptions of the systems functionality seen from the users point of view (found by doing Preliminary study)
- Use case diagram is a graphic model of the system's functionality and communication with the stakeholders.
- Three use case description formats:
- Brief: textual description of a happy days scenario
- Casual: Includes variations of happy days scenario
- Fully dressed: Includes variations of happy days scenario and failures
- A domain model describes information requirements.
- Visual representation of conceptual classes or real-world objects in a domain of interest.
- A conceptual class e.g. has:
- name
- attributes (names)
- 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.
- The operation contract describes in detail what state the domain model is in after the system operation has finished.
- In a way the contract ties the functionality (use cases) and the information (domain models) together.
- Interaction diagram describes interaction between different elements in the model (like classes, objects ...).
- 1.Communication diagram (more like design class diagram)
- 2.Sequence diagram
- The design classes to be included in the use case realization is found based on the layered architecture and the domain model.
- A design class diagram contains:
- Classes and associations, interfaces, methods, attributes incl. data type visibility
- A class describes a collection of objects that have similar attributes and behaviors.
- Object structures:
- Association: A relation between some objects. 1 object of a class has relation to 1 or more objects of another class.
- Composite aggregation: A whole-part hierarchy. The part only exist if the whole exist. Stronger than association.
- Class structures:
- Generalization: A hierarchical structure, where the general class (the superclass) has properties, which is common for some specialized classes (subclasses).
- As a transition to design we describe the system behavior (what the system does, not how) –by:
- system sequence diagram (one particular scenario of a use case)
- operation contracts (Give a more precise description of system behavior.)
- The layered architecture requires a design class for each layer:
- – 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.
- – Controller classes which gets the responsebilityto ”glue” the interface
- and the domain classes together.
- – Model classes which are found from the domain model over the problem area. The model classes which support the use cases are include.
- GRASP-General Responsibility Assignment Software Patterns
- GoF- Gang Of Four
- grasp patterns:
- 1. Creator (a general principle for the assignment of creation responsibilities)
- 2. Information Expert (Assign responsibility to an object having the information needed to fulfill the job)
- 3. Low coupling (two classes/components have high coupling if changes in one class/component requires changes in the other class/component as well)
- 4. Controller (Represents a receiver or handler of all system events of a use case scenario)
- 5. High cohesion (keeping parts of a code base that are related to each other in a single
- place)
- 6. Indirection ()
- 7. Polymorphism
- 8. Protected Variations
- 9. Pure Fabrication
- GoF pattern:
- 1. Singleton (Only one instance of a class is allowed)
- Waterfall: A sequentially passes through the activities requirement, design, implementation and test.
- 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)
- 1. Use-case driven
- 2. Architecture centric
- 3. Iterative and incremental development
- 4. Use of UML
- Gains from UP:
- 1. Less project failure
- 2. Early mitigation of risks
- 3. Early visible progress
- 4. Early feedback
- 5. User engagement leading to a system that more nearly meets the needs
- 6. Managed complexity
- 7. Learning from an iteration can be used in later iterations
- Unified Process phases:
- 1. Inception:
- Establish the business case for the system, define risks, scope, obtain 10% of the requirements, estimate next phase effort.
- 2. Elaboration:
- Develop an understanding of the problem domain and the system architecture, risk significant portions may be coded/tested, about 80% of major requirements identified.
- 3. Construction:
- System design, programming and testing. Building the remaining system in short iterations.
- 4. Transition
- Deploy the system in its operating environment. Deliver releases for feedback and deployment.
- Normalization
- May be used as measures to determine the quality of relation schema design:
- 1. Making sure that the semantics of the attributes is clear in the schema
- 2. Reducing the redundant information in tuples
- 3. Reducing the NULL values in the tuples
- 4. Disallowing the possibility of generating spurious tuples
- Normal forms (NF) provide formal guideline for the design of the tables.
- Normalization is the process of decomposing unsatisfactory “bad” relations by breaking up their attributes into smaller relations.
- Super Key- set of attributes whose values guarantee uniqueness of each row
- Candidate Key- a minimal super key (if you remove an attribute it is not any longer a super key)
- Primary Key- a designed candidate key
- Primary attribute- an attribute of a candidate key
- Qualifications for 1NF are:
- Contains only atomic values; There are no repeating groups
- …………………………………………………………………………………………………………
- Qualifications for 2NF are:
- Second normal form states that it should meet all the rules
- for 1NF and there must be no partial dependences of any
- of the columns on the primary key
- ………………………………………………………………………………………………………..
- Qualifications for 3NF are:
- is in 2nd NF and all non primary fields are dependent on the primary key
- …………………………………………………………………………………………………………
- Qualifications for BCNF are: (Boyce-Codd normal form)
- if one field in different table is changed than changes are made to everybody who uses this row. (not original definition probably even wrong)
- Defining Software Quality: Three Aspects:
- 1. Functional quality means that the software correctly performs the tasks it’s intended to do for its users.
- 2.Structural quality, means that the code itself is well structured.
- 3.The quality of the development process significantly affects the value received by users, development teams, and sponsors.
- Patterns:
- Adapter (bridge between two incompatible interfaces)
- Factory (one object responsible for creation for of closely related objects)
- Singleton (create one instance of class)
- Strategy (behavior or algorithm can be changed at run time depending on neccasity)
- Business
- SWOT (strengths weaknesses opportunities threats)is useful when defining strategy
- PESTEL (when looking to create business in different country) :
- Political
- Environment
- Social
- Technological
- Legal factors
- Economical
- Porter 5 forces – Industry analysis, shows competitive situation (threat of new entry, competitive rivalry, Buyer power, Threat of substitution, Supplier power)
- 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
- 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
- The three elements of a vision:
- 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
- 2. A tangible goal - a clear, specific, and compelling goal should be framed to focus peoples efforts.
- 3. An image of results – The image should paint a compelling picture using “crisp” language.
- The business case defines what is to be done, why, and what are the timescales and costs involved.
- Stakeholders- a person, group or organization with an interest in a project.
- 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.
- organizational structure- An organizational structure defines how activities such as task allocation, coordination and supervision are directed toward the achievement of organizational aims.
- Stakeholder analysis- impact of a decision on relevant parties.
- E-business- a term which can be used for any kind of business or commercial transaction that includes sharing information across the Internet.
- Project- complex, non-routine, one time effort limited by time, budget, resources and performance specifications designed to meet costumer needs.
- 1. Defining
- 2. Planing
- 3. Executing
- 4. Delivering
- Atomic- cannot further divide.
- Work breakdown (WBD)- approach to consider what has to be done to meet project objectives.
- Inbound logistics- The management of material resources entering an organization from its suppliers and other partners.
- 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