Assalamualaikum and good evening....
Girls... as a reminder, this is the format of the final exam paper for Software Engineering...
Our lecturer, Puan Badariah told us about the exam format in our last class...which was on Tuesday...
There will be 3 sections in the final exam :
Section A (16 q) - Fill in the blanks ( 20 blanks) - 20 marks
Section B (7 q) - Short answers (differentiate, lists, draw, definition ) - 50 marks
Section C (2 q) - Understanding, memory recall, C codes - 15 marks
Don't forget to put examples for the questions that require detail explainations...
So,girls... please be prepared for the final examination paper which will be held one week after our Hari Raya break...
Thank you...
Saturday, October 6, 2007
Thursday, October 4, 2007
Last lecture..
Chapter 11 : Maintaining the System
11.1 The Changing System
Maintenance: any work done to change the system after it is in operation.
Software does not degrade or require periodic maintenance.
Lehman’s System Types :
1. S-system: formally defined, derivable from a specification.
2. P-system: requirements based on approximate solution to a problem, but real-
world remains stable.
3. E-system: embedded in the real world and changes as the world does.
11.2 The Nature of Maintenance
Types of Maintenance :
1. Corrective: maintaining control over day-to-day functions.
2. Adaptive: maintaining control over system modifications.
3. Perfective: perfecting existing functions.
4. Preventive: preventing system performance from degrading to unacceptable
levels.
Who Performs Maintenance :
1. Separate maintenance team
2. Part of development team.
11.3 Maintenance Problems
· Staff problems: Limited understanding, management priorities and morale.
· Technical problems: Artifacts and paradigms and testing difficulties.
11.4 Measuring Maintenance Characteristics : Maintainability is not only restricted to code, but also including specification, design, and test plan documentations. Maintainability can be viewed in two ways, either external view of the software or internal view of the software.
11.5 Maintenance Techniques and Tools
· Configuration management
– Configuration control board
– Change control
· Impact analysis
· Automated maintenance tools
11.6 Software Rejuvenation
1. Redocumentation: static analysis adds more information.
2. Restructuring: transform to improve code structure.
3. Reverse engineering: recreate design and specification information from the code.
4. Reengineering: reverse engineer and then make changes to specification and design
to complete the logical model; then generate new system from revised specification
and design
11.7 Information System Example
Piccadilly System
- The software can not be an S-system.
- The software can not be a P-system.
- The software must be E-system.
11.8 Real Time Example : Developers focused on mitigating random failure. The inertial reference system failed because of a design fault, not a result of a random failure. Needs to change the failure strategy and implement a series of preventive enhancements. Invokes change control and configuration management
11.1 The Changing System
Maintenance: any work done to change the system after it is in operation.
Software does not degrade or require periodic maintenance.
Lehman’s System Types :
1. S-system: formally defined, derivable from a specification.
2. P-system: requirements based on approximate solution to a problem, but real-
world remains stable.
3. E-system: embedded in the real world and changes as the world does.
11.2 The Nature of Maintenance
Types of Maintenance :
1. Corrective: maintaining control over day-to-day functions.
2. Adaptive: maintaining control over system modifications.
3. Perfective: perfecting existing functions.
4. Preventive: preventing system performance from degrading to unacceptable
levels.
Who Performs Maintenance :
1. Separate maintenance team
2. Part of development team.
11.3 Maintenance Problems
· Staff problems: Limited understanding, management priorities and morale.
· Technical problems: Artifacts and paradigms and testing difficulties.
11.4 Measuring Maintenance Characteristics : Maintainability is not only restricted to code, but also including specification, design, and test plan documentations. Maintainability can be viewed in two ways, either external view of the software or internal view of the software.
11.5 Maintenance Techniques and Tools
· Configuration management
– Configuration control board
– Change control
· Impact analysis
· Automated maintenance tools
11.6 Software Rejuvenation
1. Redocumentation: static analysis adds more information.
2. Restructuring: transform to improve code structure.
3. Reverse engineering: recreate design and specification information from the code.
4. Reengineering: reverse engineer and then make changes to specification and design
to complete the logical model; then generate new system from revised specification
and design
11.7 Information System Example
Piccadilly System
- The software can not be an S-system.
- The software can not be a P-system.
- The software must be E-system.
11.8 Real Time Example : Developers focused on mitigating random failure. The inertial reference system failed because of a design fault, not a result of a random failure. Needs to change the failure strategy and implement a series of preventive enhancements. Invokes change control and configuration management
Wednesday, October 3, 2007
CASE TOOL For reverse engineering
here some information on reverse engineering CASE TOOL (InSight Tool):
http://ieeexplore.ieee.org/iel5/6783/18169/00841062.pdf
http://ieeexplore.ieee.org/iel5/6783/18169/00841062.pdf
Definition of Software Engineering
Software Engineering has come to mean at least two different things in our industry. First of all the term "software engineer" has generally replaced the term "programmer". So, in that sense there is a tendency to extrapolate in people's minds that Software Engineering is merely the act of programming. Secondly, the term "Software Engineering" has been used to describe "building of software systems which are so large or so complex that they are built by a team or teams of engineers. Yet, there is increasing evidence that many of the processes we have been developing for large groups of engineers also apply to the best practices of even individual engineers.
Software Engineering is intended to mean the best-practice processes used to create and or maintain software, whether for groups or individuals, in attempt to rid ourselves of the usual haphazard methods that have plagued the software industry. This would include subjects like Configuration Management, Project Planning, Project Tracking, Software Quality Assurance, Risk Management, Formal Inspections, etc.
** extra knowlegde for everybody**
Software Engineering is intended to mean the best-practice processes used to create and or maintain software, whether for groups or individuals, in attempt to rid ourselves of the usual haphazard methods that have plagued the software industry. This would include subjects like Configuration Management, Project Planning, Project Tracking, Software Quality Assurance, Risk Management, Formal Inspections, etc.
** extra knowlegde for everybody**
Subscribe to:
Posts (Atom)
