rev software engineering

7/28/2019 REV Software Engineering

1/20

Software Engineering Revision

Lec-1-Introduction

What are the main different between software

Programs and Software Products ?

Programs Software Products

* Usually small in size*Large

*Author himself is sole user

* Single developer

*Large number of users

* Lacks proper user interface *Team of developers

* Lacks proper documentation *Well-designed interface

*Well documented & user-manual prepared

* Ad hoc development. *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


2/20

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 theestablishment 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 operationand maintenance.

Case of developing bank account

o Requirements Analysis: Text producede.g., The application shall display

the balance in the users bank account.

oDesign: Diagrams and texte.g., The design will consist of the classes CheckingAccount,SavingsAccount,

o Implementation: Source and object codee.g., class CheckingAccount{ double balance; }

o Testing: Test cases and test resultse.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 texte.g., Defect repair: Application crashes when balance is $0 and attempt is made to

withdraw funds.

e.g., Enhancement: Allow operation with Euro currency.



3/20

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 Disadvantagesofthe 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.



4/20

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.



5/20

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 isalways 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



6/20

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.



7/20

Give 3 examples about risk type and software project

Risks and risk types

Risk type Possible risks

Technology

- 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.

People

- It is impossible to recruit staff with the skills required.

- Key staff are ill and unavailable at critical times.

- Required training for staff is not available.

Organizationa

l

- The organization is restructured so that different management are

responsible for the project.

- Organizational financial problems force reductions in the projectbudget.

Tools- The code generated by CASE tools is inefficient.

- CASE tools cannot be integrated.

Requirements

- Changes to requirements which require major design rework are

proposed.

- Customers fail to understand the impact of requirements changes.

Estimation

- The time required to develop the software is underestimated.

- The rate of defect repair is underestimated.

- The size of the software is underestimated.



8/20

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 requirementsRequirements 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 requirementsRequirements that are not directly related to the functions that the system must perform

Product requirementsperformance, reliability, portability, etc...

Organizational requirementsdelivery, training, standards, etc...

Marketing and public relations



9/20

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 anticipatedchanges.

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.



10/20

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 thesoftware

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 ofattributes (orfields), which have names,

types, and values.

Behavior



11/20

Defined by the set ofoperations (ormethods) 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 calledsignature. 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. Use case diagrams

2. Class diagrams

3. Object diagrams

4. Sequence diagrams

5. Collaboration diagrams

6. Statechart diagrams

7. Activity diagrams8. Component diagrams

9. Deployment diagrams

Read the following and convert it to UML Diagram

1 or more Pets associated with 1 PetOwner



12/20

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



13/20

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



14/20

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



15/20

UML Sequence Diagram



16/20

Lec-8-Design



17/20

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

Couplingoccurs 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



18/20

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



19/20

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 particularenvironments

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.



20/20

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.

rev software engineering

Documents