Thursday, February 28, 2008
System ROLLOUT!
Today is the day where our eCinema finally roll out after all the thick and thin throughout the 2month plus. We had put in alot of effort on writing the documentations and the implementing the system.
Guys,
GREAT JOB! and WELL DONE!!
The link below is to download our final documentations and system, however it is password encrypted to prevent unauthorised access. Email to ho.wei.zhe@gmail.com for the password.
http://rapidshare.com/files/95645294/HOLTZ_Corp.zip.html
Guys,
GREAT JOB! and WELL DONE!!
The link below is to download our final documentations and system, however it is password encrypted to prevent unauthorised access. Email to ho.wei.zhe@gmail.com for the password.
http://rapidshare.com/files/95645294/HOLTZ_Corp.zip.html
Sunday, February 24, 2008
Testing Completed
Friday, February 22, 2008
"DEADLY" ER Diagram and Class Diagram
Thursday, February 21, 2008
Tutorial 5
This Standard specifies the requirements for all SRS used in Defence Equipment.
It has a good set of safety management which clearly defines the Software Safety Plan, Software Safety, Safety Analysis, Software Safety Records Log, Software Safety Reviews and Software Safety Audits
The roles and responsibilities clearly define the different type of authorities needed for authorization and also the various teams needed for the development of the SRS.
The report has a good development plan which includes a detail risk analysis, Verification and Validation procedures, Configuration Management, a good set of design practices and also a detail breakdown of the selection of language and tools.
A detail breakdown of the development process principles, software requirements and the design and coding process. It also clearly defines the testing rules and how the testing must follow the principles of testing.
As for the certification rules, the Software Design Authority shall submit an SRS Certificate of Design to the Design Authority prior to delivery of the SRS to the Design Authority. Acceptance testing shall be carried out prior to acceptance of the SRS by the MOD PM.
It has a good set of safety management which clearly defines the Software Safety Plan, Software Safety, Safety Analysis, Software Safety Records Log, Software Safety Reviews and Software Safety Audits
The roles and responsibilities clearly define the different type of authorities needed for authorization and also the various teams needed for the development of the SRS.
The report has a good development plan which includes a detail risk analysis, Verification and Validation procedures, Configuration Management, a good set of design practices and also a detail breakdown of the selection of language and tools.
A detail breakdown of the development process principles, software requirements and the design and coding process. It also clearly defines the testing rules and how the testing must follow the principles of testing.
As for the certification rules, the Software Design Authority shall submit an SRS Certificate of Design to the Design Authority prior to delivery of the SRS to the Design Authority. Acceptance testing shall be carried out prior to acceptance of the SRS by the MOD PM.
Wednesday, February 20, 2008
Meeting on 19 Feb 2008
Finally after weeks of coding, the program is finally completed. We are entering the testing stage now. In the discussion, we will be finalizing the test plan, test schedule and test cases. We are also in the stage of confirming the sequence diagram.
Below is the minutes for the meeting:
http://www.freewebs.com/holtz311/meeting20080219v03.pdf
Below is the minutes for the meeting:
http://www.freewebs.com/holtz311/meeting20080219v03.pdf
Tuesday, February 19, 2008
Thursday, February 14, 2008
Tutorial 4
Task 3: Reusability can enhance the level of reliability to the software product as changes can be made to the software easily. As the reusability is high, less or no changes are required therefore making the system more reliable.
Task 4: A high portability program will greatly enhance its reusability as the same program can be used across different platforms/systems. Minimum or no re-coding is required when there is a change of environment.
Task 4: A high portability program will greatly enhance its reusability as the same program can be used across different platforms/systems. Minimum or no re-coding is required when there is a change of environment.
Wednesday, February 13, 2008
Meeting on 12 Feb 2008
This is the fourth meeting, we are glad that there have been much progress since the last meeting. We have invited our customer Mr Liaw into our meeting and have presented to him our progress so far. We are very much into the design phase and are finalizing most of the previous deliverables.
Below is the minutes for the meeting:
http://www.freewebs.com/holtz311/meeting20080212v03.pdf
Below is the minutes for the meeting:
http://www.freewebs.com/holtz311/meeting20080212v03.pdf
Tuesday, February 12, 2008
Tutorial 3
Internal
- Correctness (eg. Project conforms to the Specification)
- Verifiability (eg. Every branch/statement can be tested)
- Understandability (eg. Project can be understood at one look)
- Visibility (eg. Good Documentation)
- Reliability (eg. Minimun Downtime)
- Usability (eg. System is easy to use)
- Interoperability (eg. Replacing a broken part of a gun with a similar part from another gun)
- Robustness (eg. Reasonable Response to Incorrect Input)
- Performance (eg. Fast processing time)
- Productivity (eg. Efficient process results in faster delivery of product)
- Maintainability (eg. Ease of maintaining the system)
- Reusability (eg. Standard components can be used across many different modules)
- Portability (eg. Can be used in both windows and linux environment)
- Timeliness (eg. Delivery of product on time)
Wednesday, February 6, 2008
Happy New Year To All
HOLTZ project team would like to wish all a Happy Chinese New Year. Lets have a properous new year ahead. CHEERS!!!
Tuesday, February 5, 2008
Great News !
We are on TIME!!!
Keep it up guys!
ROAR!!!
Take a look at our schedule!
http://www.freewebs.com/holtz311/Project%20Planned%20Schedule%20v0.2.pdf
Keep it up guys!
ROAR!!!
Take a look at our schedule!
http://www.freewebs.com/holtz311/Project%20Planned%20Schedule%20v0.2.pdf
Monday, February 4, 2008
A glimpse of the prototype
Friday, February 1, 2008
Brief Introduction of project team
Thursday, January 31, 2008
Tutorial 2 and 3rd meeting
Tutorial 2: To Identify the main stakeholders for the tutorial task 1
1. Users
2. Client Management
3. Trainers
4. Technical Support
5. Premises Management
6. Catering Service
7. Document Services
In the meeting, we have reviewed the draft copies of our software project plan. We have also look at our various deliverables like ER-diagram and data dictionary. We have also discussed on the use cases and functional/non-functional requirements. During the meeting, tasks has been allocated to each team member for the coming 2 weeks as we will not be having our weekly meeting during chinece new year.
Below is the minutes for the meeting:
http://www.freewebs.com/holtz311/meeting20080131v02.pdf
Thursday, January 24, 2008
Tutorial 1 and 2nd Meeting on 24 Jan 08
Tutorial 1: In this tutorial we discussed on the various Software Project Plan, below are our findings.
Rspa
Pros
1. Simple and generic style
Cons
1. No example to follow
2. Too generic and vague description
Dsdm
Pros
1. Professional style
2. Examples given
Cons
1. Too detail and complex
2. Takes time to understand and comprehend
UPEDU
Pros
1. Easy to understand and comprehend
Cons
1. Moderate detail
Software Project Plan from Chair of Software Engineering at ETH Zurich, Switzerland
Pros
1. Covers all managerial aspects of a project
2. Easy to understand
3. Useful help given
Cons
1. Too much detail
Conclusion: After some discussion, we have decide to adopt the last option which is the project plan from Chair of Software Engineering at ETH Zurich, Switzerland. Main reason is that it allows us to generate a comprehensive report in a short time constraint.
In the meeting, we have reviewed the draft copies of our software project plan and software requirement spec. We have also started discussion on our design specs.
Below is the minutes for the meeting:
http://www.freewebs.com/holtz311/meeting20080124v02.pdf
Rspa
Pros
1. Simple and generic style
Cons
1. No example to follow
2. Too generic and vague description
Dsdm
Pros
1. Professional style
2. Examples given
Cons
1. Too detail and complex
2. Takes time to understand and comprehend
UPEDU
Pros
1. Easy to understand and comprehend
Cons
1. Moderate detail
Software Project Plan from Chair of Software Engineering at ETH Zurich, Switzerland
Pros
1. Covers all managerial aspects of a project
2. Easy to understand
3. Useful help given
Cons
1. Too much detail
Conclusion: After some discussion, we have decide to adopt the last option which is the project plan from Chair of Software Engineering at ETH Zurich, Switzerland. Main reason is that it allows us to generate a comprehensive report in a short time constraint.
In the meeting, we have reviewed the draft copies of our software project plan and software requirement spec. We have also started discussion on our design specs.
Below is the minutes for the meeting:
http://www.freewebs.com/holtz311/meeting20080124v02.pdf
First Meeting on 19 Jan 2008
Team Members:
S8539305G Ho Wei Zhe
S8337246Z Lim Yong Keong
S8437490C Zhuo Senxian
S8321012E Oh Chin Hock
S8530018J Tan Boon Chin
Our first meeting was conducted on 19 Jan 2008, we first formed our group and sit down to get to know each other. HOLTZ was agreed as our company name, it was formed using the first letter of all our sir names (Ho, Oh, Lim, Tan & Zhuo) .
Our discussed on the roles of each member and came out with the below team.
Project Manager : Ho Wei Zhe
System Requirement/Change Management Lead: Lim Yong Keong
Technical Development/System Architect Design/Quality Assurance Lead : Zhuo Senxian
Graphical Interface/Configuration Lead: Oh Chin Hock
System Testing/Validation Lead: Tan Boon Chin
During the meeting, we went through the case scenario together and came out with a project strategy.
Below file is our minutes of meeting for 19 Jan 2008
http://www.freewebs.com/holtz311/meeting20080119v02.pdf
S8539305G Ho Wei Zhe
S8337246Z Lim Yong Keong
S8437490C Zhuo Senxian
S8321012E Oh Chin Hock
S8530018J Tan Boon Chin
Our first meeting was conducted on 19 Jan 2008, we first formed our group and sit down to get to know each other. HOLTZ was agreed as our company name, it was formed using the first letter of all our sir names (Ho, Oh, Lim, Tan & Zhuo) .
Our discussed on the roles of each member and came out with the below team.
Project Manager : Ho Wei Zhe
System Requirement/Change Management Lead: Lim Yong Keong
Technical Development/System Architect Design/Quality Assurance Lead : Zhuo Senxian
Graphical Interface/Configuration Lead: Oh Chin Hock
System Testing/Validation Lead: Tan Boon Chin
During the meeting, we went through the case scenario together and came out with a project strategy.
Below file is our minutes of meeting for 19 Jan 2008
http://www.freewebs.com/holtz311/meeting20080119v02.pdf
Subscribe to:
Posts (Atom)