Upload
karim-ali-mohamed
View
218
Download
0
Embed Size (px)
Citation preview
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
7/28/2019 REV Software Engineering
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.
Software Engineering Page 2
7/28/2019 REV Software Engineering
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.
Software Engineering Page 3
7/28/2019 REV Software Engineering
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.
Software Engineering Page 4
7/28/2019 REV Software Engineering
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
Software Engineering Page 5
7/28/2019 REV Software Engineering
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.
Software Engineering Page 6
7/28/2019 REV Software Engineering
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.
Software Engineering Page 7
7/28/2019 REV Software Engineering
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
Software Engineering Page 8
7/28/2019 REV Software Engineering
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.
Software Engineering Page 9
7/28/2019 REV Software Engineering
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
Software Engineering Page 10
7/28/2019 REV Software Engineering
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
Software Engineering Page 11
7/28/2019 REV Software Engineering
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
Software Engineering Page 12
7/28/2019 REV Software Engineering
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
Software Engineering Page 13
7/28/2019 REV Software Engineering
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
Software Engineering Page 14
7/28/2019 REV Software Engineering
15/20
UML Sequence Diagram
Software Engineering Page 15
7/28/2019 REV Software Engineering
16/20
Lec-8-Design
Software Engineering Page 16
7/28/2019 REV Software Engineering
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
Software Engineering Page 17
7/28/2019 REV Software Engineering
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
Software Engineering Page 18
7/28/2019 REV Software Engineering
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.
Software Engineering Page 19
7/28/2019 REV Software Engineering
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.