Software Engineering Revision

Lec-1-Introduction

What are the main different between software Programs and Software Products ?
Programs Software Products

* * * * * *

Usually small in size Author himself is sole user Single developer Lacks proper user interface Lacks proper documentation Ad hoc development.

*Large *Large number of users *Team of developers *Well-designed interface *Well documented & user-manual prepared *Systematic development

Give 5 examples for the Main causes of software failures

Customer needs are misunderstood or not fully captured; Customer requirements change too frequently; Customers are not prepared to commit sufficient resources to the project; Customers do not want to cooperate with developers; Customers have unrealistic expectations; The system is no longer in benefit to customers; The developers may not be up to the task.

Software Engineering

Page 1

Give definition for the software engineering. then apply the software process describe the case of developing bank account for a person
Software Engineering is an engineering discipline which is concerned the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. Software engineering is the discipline concerned with the application of theory, knowledge, and practice for effectively and efficiently building software systems that satisfy the requirements of users and customers. Software engineering is applicable to small, medium, and large-scale systems. It encompasses all phases of the life cycle of a software system. The life cycle includes requirement analysis and specification, design, construction, testing, and operation and maintenance.

Case of developing bank account

o Requirements Analysis: Text produced
e.g., The application shall display the balance in the users bank account.

o Design: Diagrams and text

e.g., The design will consist of the classes CheckingAccount, SavingsAccount,

o Implementation: Source and object code

e.g., class CheckingAccount{ double balance; }

o Testing: Test cases and test results

e.g., With test case: deposit $44.92 / deposit $32.00 / withdraw $101.45 / the balance was $2938.22, which is correct.

o Maintenance: Modified design, code, and text

e.g., Defect repair: Application crashes when balance is $0 and attempt is made to withdraw funds. e.g., Enhancement: Allow operation with Euro currency.

Software Engineering

Page 2

What are the parameters that can describe the software Quality?
Usability Users can learn it and fast and get their job done easily Efficiency It doesnt waste resources such as CPU time and memory Reliability It does what it is required to do without failing Maintainability It can be easily changed Reusability Its parts can be used in other projects, so reprogramming is not needed

Lec-2-softeare process

What are the Advantages and the Disadvantages of the Waterfall Model?
Advantages:
Process visibility Separation of tasks Quality control at each step Cost monitoring at each step

Disadvantages:
Each stage in the process reveals new understanding of the previous stages, that often requires the earlier stages to be revised.

Software Engineering

Page 3

Draw diagram for Modified Waterfall Model

What is the meaning of CASE tool and what are its classifications

Computer-Aided Software Engineering (CASE) is software to

support software development and evolution processes.

CASE classification

Classification helps us understand the different types of CASE tools and their support for process activities. Functional perspective Tools are classified according to their specific function. Process perspective Tools are classified according to process activities that are supported. Integration perspective Tools are classified according to their organisation into integrated units.

Software Engineering

Page 4

Lec-3-Project management

What is Software project management And what are the software management activities ? Software project management:
Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software Project Management Activities Establish project objectives Defining work requirement Determining work timing Establishing resource availability and requirements Establishing a cost baseline Evaluating and optimizing the baseline plan Freezing the baseline plan Tracking the actual costs Comparing the progress and cost to the baseline plan Evaluating performance Forecasting, analyzing and recommending corrective action

Software Engineering

Page 5

Give 5 Examples about project management problems

Project Management Problems Resources inadequate Meeting (unrealistic) deadlines Unclear goals/direction Team members uncommitted Insufficient planning Breakdowns in communications Changes in goals and resources Conflicts between departments or functions

In the Context of Project scheduling what are the mean of : Milestone , Activity, Dependency, Slack .
Milestone Completion of a specified set of activities (e.g., delivery of a report, completion of part of the system design) Activity Part of a project that takes place over time (also called a task).

Dependency An activity that cannot begin until some event is reached Slack The amount that an activity can be delayed without delaying the next milestone.

Software Engineering

Page 6

Give 3 examples about risk type and software project

Risks and risk types Risk type
Technology

Possible risks
- The database used in the system cannot process as many transactions per second as expected. - Software components which should be reused contain defects which limit their functionality. - It is impossible to recruit staff with the skills required.

People

- Key staff are ill and unavailable at critical times. - Required training for staff is not available. - The organization is restructured so that different management are responsible for the project. - Organizational financial problems force reductions in the project budget. - The code generated by CASE tools is inefficient. - CASE tools cannot be integrated. - Changes to requirements which require major design rework are proposed. - Customers fail to understand the impact of requirements changes. - The time required to develop the software is underestimated.

Organizationa l

Tools

Requirements

Estimation

- The rate of defect repair is underestimated. - The size of the software is underestimated.

Software Engineering

Page 7

What are the process of risk management?

Risk identification
Identify project, product and business risks

Risk analysis
Assess the likelihood and consequences of these risks

Risk planning
Draw up plans to avoid or minimise the effects of the risk

Risk monitoring
Monitor the risks throughout the project

Lec-4-Requirments

What are the different between Functional requirements and Non-functional Requirements?
Functional requirements
Requirements about the functions that the system must perform that will be identified by analyzing the use made of the system Functionality Data User interfaces

Non-functional requirements
Requirements that are not directly related to the functions that the system must perform

Product requirements
performance, reliability, portability, etc...

Organizational requirements
delivery, training, standards, etc...

Marketing and public relations

Software Engineering

Page 8

What is the Requirements Document Structure looks like ?

Requirements Document Structure
Introduction (Requirements Definition) Describe need for the system and how it fits with business objectives. Functional Requirements Describe the services to be provided in detail. Non-functional Requirements Define constraints on the system and the development process. System Evolution Define fundamental assumptions on which the system is based and anticipated changes. Glossary Define technical terms used. Index

What is the meaning of Requirements Verifiability and Requirements Validation ?

Requirements Verifiability
Requirements should be written so that they can be verified objectively. The problem with this requirement is its use of vague terms such as errors shall be minimized The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. The error rate should be been quantified. Experienced controllers should be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.

Software Engineering

Page 9

Requirements Validation
Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important. Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. Prototyping is an important technique of requirements validation.

Show how you can check the requirement of the software

Validity: Does the system provide the functions which best support the customers needs? Consistency: Are there any requirements conflicts? Completeness: Are all functions required by the customer included? Realism: Can the requirements be implemented given available budget and technology?

Lec-5-Object-Oriented Programming

What are the components of an object?

Object = Identity + State + Behavior Identity Distinguishes an object from all other objects. State Consists of a set of attributes (or fields), which have names, types, and values. Behavior

Software Engineering

Page 10

 Defined by the set of operations (or methods) that may operate on the object. Each method has a name, a type, and a value, where The type consists of the return type and the list of parameter types of the method, often called signature. The value is the implementation of the method often expressed as a sequence of statements, in languages like Java and C++. Lec-6-UML

Name 5 Diagrams used in UML

1. 2. 3. 4. 5. 6. 7. 8. 9. Use case diagrams Class diagrams Object diagrams Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams Component diagrams Deployment diagrams

Read the following and convert it to UML Diagram

1 or more Pets associated with 1 PetOwner

Software Engineering

Page 11

 1 CPU associated with 0 or more Controllers 1-4 DiskDrives associated with 1 SCSIController SCSIController is a (specialized) Controller
Computer System

1 Bank associated with 0 or more Accounts Checking, Savings, MoneyMarket are Accounts
Banking System

Software Engineering

Page 12

 Each Thermostat has 1 Room Each Thermostat associated with 0 or more Heaters ElectricHeater is a specialized Heater AubeTH101D is a specialized Thermostat
Home heating system

Software Engineering

Page 13

Lec-7-UML

Apply the UML State Diagram and the UML Sequence Diagram to describe the work flow of the dispenser Machine
UML State Diagram

Software Engineering

Page 14

UML Sequence Diagram

Software Engineering

Page 15

Lec-8-Design

Software Engineering

Page 16

What are the design principles describe 5 of them

Design Principle 1: Divide and conquer Trying to deal with something big all at once is normally much harder than dealing with a series of smaller things Separate people can work on each part. An individual software engineer can specialize. Each individual component is smaller, and therefore easier to understand. Parts can be replaced or changed without having to replace or extensively change other parts. Design Principle 2: Increase cohesion where possible A subsystem or module has high cohesion if it keeps together things that are related to each other, and keeps out other things This makes the system as a whole easier to understand and change Type of cohesion: Functional, Layer, Communicational, Sequential, Procedural, Temporal, Utility Design Principle 3: Reduce coupling where possible Coupling occurs when there are interdependencies between one module and another When interdependencies exist, changes in one place will require changes somewhere else. A network of interdependencies makes it hard to see at a glance how some component works.

Design Principle 4: Keep the level of abstraction as high as possible

Software Engineering

Page 17

 Ensure that your designs allow you to hide or defer consideration of details, thus reducing complexity A good abstraction is said to provide information hiding Abstractions allow you to understand the essence of a subsystem without having to know unnecessary details Design Principle 5: Increase reusability where possible Design the various aspects of your system so that they can be used again in other contexts Generalize your design as much as possible Follow the preceding three design principles Design your system to contain hooks Simplify your design as much as possible Design Principle 6: Reuse existing designs and code where possible Design with reuse is complementary to design for reusability Actively reusing designs or code allows you to take advantage of the investment you or others have made in reusable components Design Principle 7: Design for flexibility Actively anticipate changes that a design may have to undergo in the future, and prepare for them Reduce coupling and increase cohesion Create abstractions Do not hard-code anything Leave all options open Do not restrict the options of people who have to modify the system later Use reusable code and make code reusable

Design Principle 8: Anticipate obsolescence

Software Engineering Page 18

 Plan for changes in the technology or environment so the software will continue to run or can be easily changed Avoid using early releases of technology Avoid using software libraries that are specific to particular environments Avoid using undocumented features or little-used features of software libraries Avoid using software or special hardware from companies that are less likely to provide long-term support Use standard languages and technologies that are supported by multiple vendors Design Principle 9: Design for Portability Have the software run on as many platforms as possible Avoid the use of facilities that are specific to one particular environment E.g. a library only available in Microsoft Windows Design Principle 10: Design for Testability Take steps to make testing easier Design a program to automatically test the software Design Principle 11: Design defensively Never trust how others will try to use a component you are designing Handle all cases where other code might attempt to use your component inappropriately Check that all of the inputs to your component are valid.

Software Engineering

Page 19

What are the Techniques for making good design decisions

Using priorities and objectives to decide among alternatives Step 1: List and describe the alternatives for the design decision. Step 2: List the advantages and disadvantages of each alternative with respect to your objectives and priorities. Step 3: Determine whether any of the alternatives prevents you from meeting one or more of the objectives. Step 4: Choose the alternative that helps you to best meet your objectives. Step 5: Adjust priorities for subsequent decision making.

Software Engineering

Page 20