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 complete,consistent,unambigious,correct,ralistic,verifiable,traceable

1.1.2. Types of Req. Elicitation. Greenfield Engineerying ReEngineering Project Interface Envineering

1.1.3. Quality Requirements Usability, Robustness, Availablility

1.1.4. Types of Requirements Functional Requirements NonFunctional Requirements techniques to elicit rewuirements

1.2. Activities.

1.2.1. Identify actors

1.2.2. Identify Scenarios AsIs / Visionary / Evaluation / Training How to find them Questions to ask, Examplse of them

1.2.3. Identifying Use Cases Section of textual ones Exceptios

1.2.4. Use Case Diagrams Identifying Use Cases Refining use cases Go Back to client Identifying relations+actors between actors + use cases Communication extend include

1.2.5. Identify Initial Analysis Objects Participation objects for each use case

1.2.6. Identify NonFunctional Requirements FURPS Functionality Usability Reliability Performance Supportability

1.3. Management

1.3.1. JAD

1.3.2. Tracability maintainance

1.3.3. Documentation


1.4.1. NonFunctional Requirements

1.4.2. Functional Model Use Case Diagrams

2. 2- Analysis

2.1. Analysis Objject Model

2.1.1. Steps to get objects Identify Classes, Attributes, Associations and operations generalisation + specialization + aggregations types Entity, Boundary, Control (=how to identify?)

2.1.2. Approaches Application domain approach (x) Syntactic Approach (Y) Find participating objects (how) look at verbsd nouns design pattern approach(x) component based approach(x)

2.2. Dynamic Model

2.2.1. Sequence Diagram(Iteration) Fork and Stair

2.2.2. Communication diagram (sequence diagram derivitave)

2.2.3. StateChart Diagram events,transitions, AND


2.3.1. Analysis Object Model Class Diagram

2.3.2. Dynamic Model Sequence Diagram DYNAMIC CONNDTION = same methods in sequence and class diagrams statechart

3. 3. Ssytem Design(ch6+7)


3.1.1. Design Goals

3.1.2. Subsystem Decomposition 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) Layers and Parittions Open/Closed Repository MovelViewController(x) Client/Server Peer to Peeer 3 Tier Pipe and Filter(x) 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) flatfile good for lots of small data but bad for concurrency relational dv good for lots of data + concurrancy but bad for small sets of data OOP DB good for irregular associations, medium size, but slow.

3.4.4. Provide access controll (X)

3.4.5. Design Global control flow Implicit Explicit Centeralised control(FORK) decenteralised control(STAIR) 2 things are inheritly concurrent if they can recieve 2 things at the saemt times without interacitng 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 INCLUDE 3 more circles, STARTUP,SHITDOWN,CONFIGURE exception handingling EXCEND error

4. 4. Object Design(ch8+9)

4.1. Reuse

4.1.1. Reuse White Box Implmentation inheritence Specification inheritence Black Box Delegation Frameworks White box Black box Concepts Inheritence, Abstract methods, Interfaces Select Design patterns Bridge pattern Adapter pattern Strategy pattern Abstract Factory pattern Composite pattern Facade pattern

4.1.2. Interface Specification of the subsystem services Role of developers Contracts Invariant postcondition precondition OCL

4.2. Model>Code

4.2.1. Restructuring

4.2.2. Optimistaion


4.3.1. Object design model 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 Application domain 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 developer What each of these guys do. examples liasion manager consultant Participatiation 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. - task specified by work package(completion criteria, risks,description) activity = large unit

9.3. communication mechanisisms

9.3.1. synchronous hallway/meeting(smokesignals)

9.3.2. asynchronous 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 problem definition project review client review status review release postmortom

9.5.2. unplanned commmunication requrest for clarificaiton /change 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 Class diagram

10.2.2. during system design is is the system design object model includes subsystem interface stuff

10.2.3. during objject design it is the object design model includes detailed descriptions of solution objects

10.3. Dynami Model

10.3.1. interaction,state,actuvuty