SoftwareEnginerring

Get Started. It's Free
or sign up with your email address
Rocket clouds
SoftwareEnginerring by Mind Map: SoftwareEnginerring

1. Requirements Elecititation

1.1. Concepts

1.1.1. Requirements Validation

1.1.1.1. complete,consistent,unambigious,correct,ralistic,verifiable,traceable

1.1.2. Types of Req. Elicitation.

1.1.2.1. Greenfield Engineerying

1.1.2.2. ReEngineering Project

1.1.2.3. Interface Envineering

1.1.3. Quality Requirements

1.1.3.1. Usability, Robustness, Availablility

1.1.4. Types of Requirements

1.1.4.1. Functional Requirements

1.1.4.2. NonFunctional Requirements

1.1.4.2.1. techniques to elicit rewuirements

1.2. Activities.

1.2.1. Identify actors

1.2.2. Identify Scenarios

1.2.2.1. AsIs / Visionary / Evaluation / Training

1.2.2.2. How to find them

1.2.2.2.1. Questions to ask,

1.2.2.2.2. Examplse of them

1.2.3. Identifying Use Cases

1.2.3.1. Section of textual ones

1.2.3.1.1. Exceptios

1.2.4. Use Case Diagrams

1.2.4.1. Identifying Use Cases

1.2.4.2. Refining use cases

1.2.4.2.1. Go Back to client

1.2.4.3. Identifying relations+actors between actors + use cases

1.2.4.3.1. Communication

1.2.4.3.2. extend

1.2.4.3.3. include

1.2.5. Identify Initial Analysis Objects

1.2.5.1. Participation objects for each use case

1.2.6. Identify NonFunctional Requirements

1.2.6.1. FURPS

1.2.6.1.1. Functionality

1.2.6.1.2. Usability

1.2.6.1.3. Reliability

1.2.6.1.4. Performance

1.2.6.1.5. Supportability

1.3. Management

1.3.1. JAD

1.3.2. Tracability maintainance

1.3.3. Documentation

1.4. OUTPUTS:

1.4.1. NonFunctional Requirements

1.4.2. Functional Model

1.4.2.1. Use Case Diagrams

2. 2- Analysis

2.1. Analysis Objject Model

2.1.1. Steps to get objects

2.1.1.1. Identify Classes, Attributes, Associations and operations generalisation + specialization + aggregations

2.1.1.2. types

2.1.1.2.1. Entity, Boundary, Control (=how to identify?)

2.1.2. Approaches

2.1.2.1. Application domain approach (x)

2.1.2.2. Syntactic Approach (Y)

2.1.2.2.1. Find participating objects (how)

2.1.2.2.2. look at verbsd nouns

2.1.2.3. design pattern approach(x)

2.1.2.4. component based approach(x)

2.2. Dynamic Model

2.2.1. Sequence Diagram(Iteration)

2.2.1.1. Fork and Stair

2.2.2. Communication diagram (sequence diagram derivitave)

2.2.3. StateChart Diagram

2.2.3.1. events,transitions, AND

2.3. OUTPUTS:

2.3.1. Analysis Object Model

2.3.1.1. Class Diagram

2.3.2. Dynamic Model

2.3.2.1. Sequence Diagram

2.3.2.1.1. DYNAMIC CONNDTION = same methods in sequence and class diagrams

2.3.2.2. statechart

3. 3. Ssytem Design(ch6+7)

3.1. OUTPUTS:

3.1.1. Design Goals

3.1.2. Subsystem Decomposition

3.1.2.1. software arfhecdihne

3.1.3. Object Design Model

3.2. Decompose the system

3.2.1. Subsystems

3.2.2. Services and subsystem interfaces

3.2.3. ball+socket notatio

3.2.4. Coupling and Cohesion

3.2.5. Architectural styles(decomp methods)

3.2.5.1. Layers and Parittions

3.2.5.1.1. Open/Closed

3.2.5.2. Repository

3.2.5.3. MovelViewController(x)

3.2.5.4. Client/Server

3.2.5.5. Peer to Peeer

3.2.5.6. 3 Tier

3.2.5.7. Pipe and Filter(x)

3.2.5.8. the Software Architecture IS a architectural style, which is a way of decomposing a systems

3.3. Identify design goals

3.3.1. Format

3.3.2. Perfofmance, dependability,cost,maintainability

3.3.3. Trade off's

3.4. Addressing Design Goals

3.4.1. Prototypes

3.4.2. Map Subsystems to Nodes

3.4.3. Identify persistant data ( types of db)

3.4.3.1. flatfile

3.4.3.1.1. good for lots of small data but bad for concurrency

3.4.3.2. relational dv

3.4.3.2.1. good for lots of data + concurrancy but bad for small sets of data

3.4.3.3. OOP DB

3.4.3.3.1. good for irregular associations, medium size, but slow.

3.4.4. Provide access controll (X)

3.4.5. Design Global control flow

3.4.5.1. Implicit

3.4.5.2. Explicit

3.4.5.2.1. Centeralised control(FORK)

3.4.5.2.2. decenteralised control(STAIR)

3.4.5.3. 2 things are inheritly concurrent if they can recieve 2 things at the saemt times without interacitng

3.4.5.4. synchronous and asynchronus messages (reply ot not in sequence diagram)

3.4.6. REVIEW it to ensure correct,complete,consistant,realistic, readable

3.4.7. boundary condiutions

3.4.7.1. INCLUDE 3 more circles, STARTUP,SHITDOWN,CONFIGURE

3.4.7.2. exception handingling

3.4.7.2.1. EXCEND error

4. 4. Object Design(ch8+9)

4.1. Reuse

4.1.1. Reuse

4.1.1.1. White Box

4.1.1.1.1. Implmentation inheritence

4.1.1.1.2. Specification inheritence

4.1.1.2. Black Box

4.1.1.2.1. Delegation

4.1.1.3. Frameworks

4.1.1.3.1. White box

4.1.1.3.2. Black box

4.1.1.4. Concepts

4.1.1.4.1. Inheritence, Abstract methods, Interfaces

4.1.1.5. Select Design patterns

4.1.1.5.1. Bridge pattern

4.1.1.5.2. Adapter pattern

4.1.1.5.3. Strategy pattern

4.1.1.5.4. Abstract Factory pattern

4.1.1.5.5. Composite pattern

4.1.1.5.6. Facade pattern

4.1.2. Interface Specification

4.1.2.1. of the subsystem services

4.1.2.2. Role of developers

4.1.2.3. Contracts

4.1.2.3.1. Invariant

4.1.2.3.2. postcondition

4.1.2.3.3. precondition

4.1.2.3.4. OCL

4.2. Model>Code

4.2.1. Restructuring

4.2.2. Optimistaion

4.3. OUTPUTS:

4.3.1. Object design model

4.3.1.1. Class Diagram

5. 5.Implementation

5.1. Activities

5.1.1. Optimisation

5.1.2. Realizing associations

5.1.3. mapping constracts to exceptions

5.1.4. Class models > Storage schema

5.2. Types of transformations

5.2.1. Model transformation

5.2.2. refactoring

5.2.3. forward engineering

5.2.4. reverse engineeringh

6. 6.Testing

7. Chapter 1

7.1. What is software enginering

7.1.1. Modeling

7.1.2. Problem solving

7.1.3. knowledge acquisition

7.1.4. rationalle

7.2. Software engineering concepts

7.2.1. Participents and roles

7.2.2. Systems and models

7.2.3. functional and nonfunctional requirements

7.3. Software engineering activities

7.3.1. ch4-5-6-7-8-9

8. Chapter 2 UML

8.1. Diagrams

8.1.1. Activity diagrams

8.1.2. StateMachines

8.1.3. Interaction diagrams

8.1.4. Class diagrams

8.1.5. Use Case Diagrams

8.2. Concepts

8.2.1. Data types

8.2.2. Class Types

8.2.3. Abstract Classes

8.2.4. OOP Modeling

8.2.4.1. Application domain

8.2.4.2. Solution domain

8.2.5. falsification and modeling

9. Chapter 3

9.1. Project organisations

9.1.1. heirachal

9.1.2. liasion

9.1.3. peer

9.1.4. roles

9.1.4.1. developer

9.1.4.1.1. What each of these guys do. examples

9.1.4.2. liasion

9.1.4.3. manager

9.1.4.4. consultant

9.1.4.5. Participatiation

9.1.4.5.1. 1-1,1-few, many to many

9.1.5. What should a project organisation define

9.2. A Project

9.2.1. Deliverables

9.2.2. schedules

9.2.3. activity

9.2.4. resource

9.2.5. -

9.2.5.1. task specified by work package(completion criteria, risks,description)

9.2.5.1.1. activity = large unit

9.3. communication mechanisisms

9.3.1. synchronous

9.3.1.1. hallway/meeting(smokesignals)

9.3.2. asynchronous

9.3.2.1. email / newsgroup / portal

9.4. organisationl activities

9.4.1. join team

9.4.2. join communication infrastructure

9.4.3. attend status meetings

9.4.4. organise client and project reviiews

9.5. communication Event

9.5.1. planned communication

9.5.1.1. problem definition

9.5.1.2. project review

9.5.1.3. client review

9.5.1.4. status review

9.5.1.5. release

9.5.1.6. postmortom

9.5.2. unplanned commmunication

9.5.2.1. requrest for clarificaiton /change

9.5.2.2. issue resolution

10. Models

10.1. Functional Model

10.1.1. use case, user POV, from req elicitation.

10.2. Object Model

10.2.1. during analysis it is the analysis object model

10.2.1.1. Class diagram

10.2.2. during system design is is the system design object model

10.2.2.1. includes subsystem interface stuff

10.2.3. during objject design it is the object design model

10.2.3.1. includes detailed descriptions of solution objects

10.3. Dynami Model

10.3.1. interaction,state,actuvuty