SDI1 week8_2

19/03/2010


 
UML

Use Case Notation

include

exclude

 

Homework

Draw use case from scenario

SDI1 week8_1

16/03/2010


 
UML (Unified Modelling Language)

UML is a standard language for specifying, visualizing, constructing, and documenting the artefacts of software systems, as well as for business modelling and other non-software systems.

If we define a new system verbally, each project member understands slightly different system. These differences affect project progress, so we have to define system visually.

 
UML diagrams

UML includes 6 types of diagram.

-          Use case diagram

-          Class diagram

-          Interaction diagram

-          State diagram

-          Activity diagram

-          Physical diagram

 
Use case diagram

Use case diagram is helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible.

SDI1 week7_2

12/03/2010

 
 

Confirm our project team risks

 
 

Requirements

 
 

• Use case
  
• Functional requirements
  
  • Functional requirements define the outward behaviour required of the software project
    
• Non Functional requirements
  
  • Non functional requirements define characteristics of the software which do not change its behaviour
    
• Software requirements specification
  

SDI1 week7_1

10/03/2010

 
 

Prioritize risks

Risk Exposure = Probability * Loss

 
 

Manage risk approach

For each risk that will be handled, you must devise and then execute risk management plans.

 
 

• Mitigation
  
• Transfer
  

 
 

Homework

Identify our team project risks

SDI1 week6_2

05/03/2010

 
Risk Management

Risk: Common sense

ex. colour, Resource, HW/SW

 

Risk = probability * impact

Qualitative: Idea/Descriptive

Quantitative: Numerically

Prioritize risks

• To prioritize risks, you need to estimate the probability of its occurrence and its consequences when its dose occur
  
• The product of these values, the expected value of the loss for the risk, can be used for prioritization
• 
  
  
  
  This expected value is called risk exposure
  RE(R) = Prob (R) * Loss(R)

Managing a Risk Approaches

• preventive or avoidance actions
  
• Mitigation
• Transfer

Risk Identification

Def: process of understanding what potential events might hurt or enhance a particular project

Risk Identification Technique

• Brainstorming
  
• The Delphi Technique
• Interviewing
• 
  
  
  
  SWOT analysis
  
  

SDI1 week6_1

03/03/2010


 
Project Schedule

Terminology

• Precedence
  
• Concurrence
  
• Leads & Lag time
  
• Milestones
  

 

Scheduling Techniques

• 
  
  Mathematical Analysis
  
  • Network Diagram
    
• 
  
  Bar Chart
  
  
  

Network Diagram

• 
  
  Activity on Arrow Network
  
  • Event is binary
    
  • Activity can be partially complete
    
• 
  
  Activity on Node Network
  • Events are shown in activity on node network unless they are milestones
    
  • Milestones are points in the project at which major portions of the work are completed
    

 

Reason for scheduling

• Ensuring that the deadline can be met
  
• 
  
  How the project should be managed
  
  
  

Critical Path

• Def: the series of activities that determines the duration of the project
  
• All project have a critical path
  
• 
  
  Critical path must do
  
  
  

PERT (Program Evaluation and Review Technique)

• Based on idea that estimates are uncertain
  
• 
  
  Uses an "expected value"
  
  
  How to estimate
  
  
  Optimistic (ex. 5Weeeks)
  
  Most likely (ex. 7weeks)
  
  Pessimistic (ex. 10weeks)
  
  
  
  PERT Formula
  
  
  te = ( a + 4m + b ) / 6
  

te	expected time
a	optimistic time estimate
m	most likely time estimate
b	pessimistic time estimate

 

ex. (5w + 4*7w + 10w) / 6 = 7.16w

 

SDI1 week5_1

24/02/2010


 
Project Scheduling

WBS: Working Breakdown Structure

Logical hierarchy that organized and breakdown the work that needs to be accomplished on a project

 

Guideline for Developing a WBS

• Develop from WBS from top down (not bottom up)
  
• Don't exceed about 5 level
  
• Someone should be assigned for each work package
  
• Check to make sure that the WBS is consistent with the project proposal
  

 

Purpose of scheduling

• Track the progress of the project
  
• Determine how possible changes might affect the project
  
• Communication
  

 

Estimation

• Effort: how much work will the activity need to be complete
  
• Resources: how many resources will be working on the activity
  
• 
  
  Duration: how long will the activity last for
  
  
  

Scheduling

Primary Object

• Best time
  
• Least cost
  
• Least risk
  

Secondary Object

• Evaluation of schedule alternatives
  
• Effective use of resources
  
• Communication
  

SDI1 week5_2

26/02/2010

Exam

2hours

Close Book

Requirements 100p

SDI1 week4_2

19/02/2010

Presentation: Project Proposal, which we chose case study from on-line shop or club web site

*This Project (on-line shop or club web site) must have uniqueness, so we think about to enhance users because of this uniqueness.

*This PJ should minimize function, but it has to be uniqueness not copy or common site.


 
Exam preparation (close book)

Week 3 and 4 PPT

1. 
   
   4, 10, 11, 14, 16, 44, 45, 48, 50, 51, 59, 60, 66, 74, 75, 76, 78, 152
   
   Case Study about TPS, MIS, DSS
   
   

SDI1 week4_1

Exam

next Friday

1. Waterfall vs Prototype (definition, stage, key word, diagram, each stage documents, type of process, Pros&Cons)
2. TPS, MIS, DSS
3. Case study
    

Project Proposal

Constrains 制限 (user, seasonal, age)

Assumption 条件

Scope Statement (which is more detailed than goal.)

In Scope : must have

Out of Scope : nice to have

Homework This Friday's presentation

SDI1 week3_2

12/02/2010

 
 

Type of Software Development

TPS : Transaction Processing System

MIS : Management information System

DSS : Decision Support System

 
 

Management Information System (MIS)

• Routine information for routine decisions
  
• Operational efficiency
  
• Use transaction data as main input
  
• Database integrate MIS in different functional areas
  

   
   

   
   

MIS output

• Schedule reports
  
• Demand reports
  
• Exception reports
  

 
 

Decision Support System

• DSS - a decision support is an organized collection of people, procedure, software, databases and devices used to support problem specific decision making.
  

   
   

Compare TPS, DSS, MIS

 
 

SDI1 week3_1

10/02/2010

 
 

Compare

• Waterfall Model
  
• Prototype Model
  

   
   

SDLC

• Requirements/Analysis
  
• Design
  
• Implement
  
• Testing
  
• Deployment
  
• Maintenance
  

   
   

Requirements : can do

Sys requirements

User requirements

Client requirements

 
 

Specification(Unique) : it is

 
 

Prototype Documentation

Client meeting

Supervisor meeting

Journal

 
 

Suggest Modeling

Initial Step	Prototype Model
And then	Chose Waterfall or Prototype Model
Or	Some degree changeable from Prototype to Waterfall Model

 
 

Prototype Model's Pros

• Better understanding of requirements
  
• Good starting point
  

Prototype Model's Cons

• The prototype may be used as a starting point rather than thrown away.
  
• The prototype typically have poor design and quality.
  
• Bad decisions during prototyping may propagate to the real product.
  

   
   

Waterfall Model vs Prototype Model

Prototype Strength

• No need much requirement/detail.
  
• Easy to accept changes in the middle of project.
  
• Usually get little resistance from users.
  
• Involve the user in analysis & design.
  

Waterfall Strength

• Can make a reliable system.
  
• Cost benefit & payback analysis are more clear & closed.
  
• Time & budget could estimate in front.
  

 
 

Prototype Weakness

• Cost benefit & payback analysis are not clear & only estimate.
  
• Budget & time must flexible.
  
• If goal not clear, subject requirements from user will involve.
  

Waterfall Weakness

• Need detail spec of what & how to get the target. (more req.)
  
• Need big effort & budget if something important change in the middle of project
  

System development integration Week2_1

Software Development Life Cycle (SDLC)

1. Requirement (Analysis)
2. Design
3. Implementation
4. Testing
5. Deployment
6. Maintenance

Waterfall Model
*It must be reviewed all broader concept phases before next step.

• System Requirement Definition (How many users? How many Locations?)
• Software Requirements Analysis
• Preliminary design
• Detailed design
• Coding and unit testing
• Component integration and testing
• Integration testing
• System testing
• Maintain software

- Pros

1. System is well documented.
2. Phases correspond with project management phases.
3. Cost and schedule estimates may be lower and more accurate.
4. Details can be addressed with more engineering effort if software is large or complex.

- Cons

1. All risks must be deal with in a single software development effort.
2. Because the model is sequential, there is only local feedback at the transaction between phases.
3. A working product is not available until late in the project.
4. Progress and success are not observable until the later stages. If a mistake or deficiency exists in the documentation of earlier phases, it may not be discovered until the product is delivered.
5. Corrections must often wait for the maintenance phase.

- Concluding

• The waterfall model can be successfully used when requirements are well understood in the beginning and are not expected to change or evolve over the project. Project risks should be relatively low.

Incremental Model
- Pros

1. Provides some feedback, allowing later development cycles to learn from previous cycles.
2. Requirements are relatively stable and may be better understood with each increment.
3. Allows some requirements modification and may allow the addition of new requirements.
4. It is more resposive to user needs than the waterfall model.
5. A usable product is available with the first release, and each cycle results in greater functionality.
6. The project can be stopped any time after the first cycle and leave a working product.
7. Risk is spread out over multiple cycles.
8. This method can usually be performed with fewer people than the waterfall model.
9. Return on investment is visible earlier for smaller, incremental project.
10. Testing may be easier on smaller portions of the system.

- Cons

1. The majority of requirements must be known in the begining.
2. Formal reviews may be more difficult to implement on incremental releases than on a complete system.
3. Because development isspread out over multiple iterations, interfaces between modules mesut be well-known defined in the beginning.
4. Cost and schedule overruns may result in an unfinished sysrtem.
5. Operations are impacted as each new release is deployed.
6. Users are required to learn how to use a new system with each deployment.

- Concluding

The incremental model is good for projects where requirements are known at beginning, but which need functionality early in the project or which can benefit from the feedback of earlier cycyles.

Evolutionary Model (Prototyping)

- Pros

1. Project can begin without fully defining or understanding requirements.
2. Final requirements are improved and more in line with real user needs.
3. Risks are spread over multiple software builds and controlled better.
4. Operational capability is achieved earlier in the program.
5. Newer technology can be incorporated into the system as it becomes available durinng later prototypes.
6. Documentation emphasizes the final product instead of the evoluition of the product.
7. This method combines a formal specification with an operational prototype.

- Cons

1. Because there are more activities and changes, there is usually an increase in both cost and schedule over the waterfall method.
2. Management activities are increased.
3. Instead of a single switch over to a new system, there is an ongoing impact to current operations.
4. Configuration management activities are increased.
5. Greater coordination of resources is required.
6. Users sometimes mistake a prototype for the final system.
7. Prototypes changes between cycles, adding a learning curve for developers and users.
8. Risks may be increased in the areas.

- Concluding

• The evolutionary model can be employed on the most type of acquisitions. However, it is usually employed on medium to high-risk systems.

System Development Integration Week2-1

Week5 Exam (close cook)
Design : functionality
Feasibility : applicable, solution
Find solution (not answer)
Analysis phase

• direct observation (must contained)

• prototype (must contained, even though we chose water fall.)

stake holder : affect company directly /indirectly
Share holder : financial input

System development integration Week1

It`s journal of my class,so I write only in English. If you are interested in Graduate Diploma in Information Technology, you can check it. Mainly this is for my own benefit.

System Development Integration Week1
- Traditional constraint points of project

• Scope
• Time
• Money

- Now constraint points of project

• Customer Satisfaction
• Quality
• Risk

- More and More complex

Definition:
- Resource = ex.people,hardware,software etc touchable things
- Projects

• developing a new software application
• implementing a new business procedure
• adding functionality to an IT system

- Functionality = expecting user action ex.2way
- Unfunctionality = not expecting user action ex.1way

- Characteristics of projects

• temporary endeavor
• unique product or service
• performed by people
• constrained by limited resources
• planned, executed and controlled
• have their own organization/structure/hierarchy order

- Activities of projects

• design of a user interface
• installation of a local area network
• integration test
• training
• implementation of a set of Java classes
• documentation of design decision and code

- Typical project management activities

• communication with team
• effort estimation
• planning activities / assigning resources
  
• comparing actual performance to plan
• risk analysis
• negotiation with subcontractors
  
• staff aquisition

- PM roles

• management
• communication
• presentation and reporting

- Project success = the specified results are delivered in the required quality and within the predetermined time and resource limits.

- Project integration management

• ensure that various elements of the project are properly coordinated
• make tradeoffs among competing objectives and alternatives
• primarily task of project manager since they are responsible for seeing the over all "big picture"