Semester Fall 2007
·
Total 15 lectures (3 Module
Course). (Some of the lectures will be Self Study)
·
Each class consists of two 45
minute lecture sessions.
PREFACE:
·
The cost of developing software worldwide is
exorbitant and grows at the rate of at least 12% a year. Thus, any
improvement in the software development process would have a strong impact on
world economy. Such improvements include improvement in the ability to
produce software as required, on time and within budget constraints.
·
However, research shows that in fact most
software projects are never delivered at all! Some need to be
rewritten and a negligible percentage are used as delivered .
Even this small percentage is not delivered on time. The problem encountered
in building large software systems is not simply a scaled version of the
problem of building small computer programs. To draw an analogy, you
would not use the same design to implement a footbridge over a stream and
a road bridge over a river. Thus, software engineering is concerned with
software systems that are too big for an individual to grasp and are built in
teams.
·
The life cycle of software development includes
its specification, design, implementation, testing and maintenance. The
order of these stages might vary, or the stages might recur in the course of
the same project. The classical waterfall model views this as a
sequential process in which the completion of each stage leads to the
next. Other software life cycle models have been proposed. For
example, in the spiral life cycle model, the process of analysis, design and
implementation is carried out repeatedly for different chunks of the
system. In this course we concentrate on the water-fall model. If
this model is understood, other models can be easily adopted.
WHAT WE WILL BE DOING IN THIS COURSE (The Objective):
WHAT YOU ARE SUPPOSE TO ACHIEVE AT COMPLETION (Hopefully ?):
SOME KEY DEFINITIONS:
Software Process
A software process is set of activities that leads the production of a software product. These activities may involve the development of software from scratch in a standard programming language like Java or C. Software processes are complex and, like all intellectual and creative processes, rely on people making decisions and judgements. Because of the need of the judgement and creativity, attempts to automate software processes have met the limited success. As discussed software processes are inherently complex and involve a very large number of activities, like products, processes also have attributes or characteristics. It is not possible to make process improvements that optimise all process attributes simultaneously. At the completion of this section, you will understand:
· The concept of software processes and software process models.
· The activities involved in software requirements engineering, software development, testing and evolution.
· The principles of software process improvement and why process improvement is worthwhile.
· How software process factors influence software quality and the productivity of software developers.
Project Management
Software project management is an essential part of software engineering. Good management cannot guarantee project success. However, bad management usually results in project failure: The software is delivered late, costs more than originally estimated and fails to meets its requirements. Software managers are responsible for planning and scheduling project development. They supervise the work to ensure that it is carried out the required standards and monitor progress to check that development in on time and within budget. The objectives of this section is to give you an overview of software project management. After completing this section you will know:
· The principal tasks of software project managers.
· Why the nature of software makes software project management more difficult than other engineering project management.
· The fundamental of software costing and reasons why the price of the software may not be directly related to its development cost.
· The key issues of team working, including team composition, team cohesiveness, team communications and team organisation.
Engineering Requirement
First stage of the waterfall model is software specification. Both formal and informal methods are used in this stage. We introduce examples of both and describe the trade-off that exists between formal and informal specification methods. Structured reviews are proven to be a key practical tool in improving the final software product and are used at the end of each stage of the waterfall model. As part of the specification process, a description of the real world entities which are to be represented in the software system is created. This is called `modelling'. Several methods which fit different contexts exist. For example, the data flow approach to modelling is appropriate in modelling the system processes while concurrent systems are best modelled using finite state machines (FSM). When the software system exports its data in a DB which is used by other programs, relational models can be used. Although formal specification methods are not widely used in the industry, they can and should be used as a complementary tool to the informal specification methods. As examples of formal specifications we discuss the use of pre- and post-conditions and algebraic specification. After completing this section you will understand:
· The difference between functional and non-functional software requirements;
· Several techniques of requirement elicitation and analysis;
· Why it is important to establish the boundaries of a system and model its context;
· The concept of behavioural modelling, data modelling and object modelling;
· Why formal specification techniques help to discover problems in system requirements.
Software Evolution
After systems have been deployed, they inevitably have to change if they are remain useful. Once software is put into use, new requirements emerge and existing requirements change. Business changes often generate new requirements for existing software. Software evolution is important because organizations are now completely dependent on their software systems and have invested millions of dollars in these systems. Their systems are critical business assets and they must invest in system change to maintain the value of these assets. The majority of the software budget in large companies is therefore devoted to maintaining existing systems. At the completion of this section you will understand:
· Different types of software maintenance and the factors that affect maintenance costs;
· The processes involved in software evolution, including the process of software re-engineering;
· The benefits and problems of reusing software when developing new systems;
· Several ways to implement software reuse.
Verification and Validation
Code inspection and code walkthrough are effective, practical ways to test programs. In addition, code testing should be conducted. A test plan is prepared based on the system design documentation. Testing is done first to the unit, then the component and only then to the entire system. There are two type of testing: black box testing and white box or code based, testing. In black box testing category partition is used on the input domain. In general, it is impossible to cover all the paths of a program. Thus, in code based testing coverage models are used which exercise only a subset of the program paths. The program paths to be covered are defined using a coverage model. Achieving a coverage model increases our confidence that a program does not contain defects. Hierarchy of coverage models is introduced to support incremental testing strategies. After completing this section you will learn:
· The distinction between software verification and software validation;
· Automated static analysis is and how it is used in verification and validation;
· Distinction between validation testing and defect testing; Understand the principles of system testing and component testing;
· Strategies used to generate system test cases and essential characteristics of software tools that support test automation.
Quality Assurance
The quality of software has improved significantly over the past 15 years. One reason for this is that companies have adopted new techniques and technology such as the use of object oriented development and associated CASE support. In addition, however, there has been a great awareness of the importance of software quality management and adoption of quality management techniques from manufacturing in the software industry. The main theme of this section is to introduce software quality management, software measurement and software configuration. At the end of this section it is expected that you will understand:
· Quality management process and central process activities of quality assurance, quality planning and quality control;
· Importance of standards in the quality management process:
· Difference between product metrics and control metrics;
· Measurement may be helpful in assessing some software quality attributes;
· Why software configuration management is required for complex software systems.
Examination:
Mailing List for Messages, Discussion,
Feedback to any thing:
Ian Sommerville, Software Engineering 8th Edition Pearson Education, 2006, ISBN 0321313798.
Literature/Resources:
R.S. Pressman and Associates, Software Engineering: A Practitioner's Approach, 6/e, 2005, McGraw-Hill Higher Education, ISBN: 0072853182.
Douglas Bell, Software Engineering for Students, 4/e, 2005, Addison-Wesley, ISBN: 0321261275.
Stephen R. Schach, Classical Software Engineering, 6/e, 2005 McGraw-Hill Higher Education, ISBN: 0-07-286551-2.
Leszek Maciaszek, Bruc Liong Practical Software Engineering: A Case Study Approach, 2004, Pearson Education, ISBN: 0321204654.
Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli Fundamentals of Software Engineering, Second Edition, 2002, Pearson Education, ISBN: 013099183x.
Vliet; H Software Engineering: Principles and Practice 2E, , Wiley UK, ISBN: 0471975087 .
Daniel Steinberg, Daniel Palmer Extreme Software Engineering: A Hands-On Approach, , 2003, Pearson Education, ISBN: 0130473812.
David Gustafson Theory and Problems of Software Engineering : Schaum's Outline Series 2002, McGraw-Hill Higher Education, ISBN: 0-07-137794-8.
Project Management Software: AdeptTracker
|
Week |
Day/Date |
Time |
Room |
Articles To Read |
Handouts |
Problems |
|
36 |
03-09-07 |
12:30 |
B202 |
Introduction
to Software Engineering, Socio-technical Systems, Tools for Software
Engineering and Project Management Articles: 1.1, 2.1, 2.2, 5.2, 5.3, 5.4. |
1.2, 1.3, 1.8, 2.1, 2.2,
2.8, 5.1, 5.6 |
|
|
05-09-07 |
12:30 |
Critical
Systems, Software Processes. Articles: 4.1, 4.2, 4.3, 4.5. |
3.2, 4.3, 4.11 |
|||
|
37 |
10-09-07 |
12:30 |
B202 |
Software
Requirements, Requirement Engineering Processes, System Modelling. Article: 6.1, 6.2, 6.3, 6.4, 6.5, 7.1, 7.2,
7.3, 7.4, 8.1, 8.2, 8.3, 8.4, 8.5. |
6.5, 6.9, 7.2, 7.3, 8.4,
8.6 |
|
|
12-09-07 |
12:30 |
Formal
Specification and Critical System Specification Articles: 9.1, 9.2, 9.3, 9.4, 10.1, 10.2,
10.3. |
9.7, 9.10, 10.4, 10.6 |
|||
|
41 |
08-10-07 |
12:30 |
B202 |
Architectural
Design, Application Architectures Articles: 11.1, 11.2 11.3,
13.1, 13.2, 13.3, 13.4 |
11.4,
11.9, 13.2 |
|
|
42 |
22-10-07 |
12:30 |
B202 |
Real
Time System Design and Design Issues. 15.1, 15.2, 15.3, 15.4, 16.1,
16.5 Rapid
Software Development, Critical System
Development. Articles: 17.1, 17.2, 17.3, 17.4, 20.1, 20.3 |
|
15.7,
16.2 17.4,
20.4 |
|
26-10-07 |
12:30 |
|||||
|
44 |
29-10-07 |
12:30 |
B202 |
Verification
and Validation, Software Testing and Critical Systems Verification Articles: 22.1, 22.4, 23.1,
23.3, 24.1 |
22.2,
23.5, 24.8, 24.10 |
|
|
31-10-07 |
12:30 |
|||||
|
45 |
05-11-07 |
Read
Chapter 26, 28 and 29 |
||||
|
07-11-07 |
||||||
|
46 |
12-11-07 |
Read
Chapter 8 & 9: Try these exercises: 8.4, 8.6, 9.7 & 9.10 |
||||
|
14-11-07 |
||||||
|
47 |
19-11-07 |
Read Chapter 18, 19
and 21: Try these exercises: 18.3, 18.7, 19.3, 19.6, 21.1 & 21.9 |
||||
|
21-11-07 |