Chapter 7 Software Engineering Objectives Understand the software life cycle. Describe the development process models.. Understand the concept of modularity.

Chapter 7 Chapter 7

Software EngineeringSoftware Engineering

Objectives

• Understand the software life cycle.

• Describe the development process models..

• Understand the concept of modularity in software engineering.

• Understand the importance of quality in software engineering.

• Understand the role of documentation in software engineering.

System life cycle

• Software, like many other products, goes through a cycle of repeating phases.

System development phases

• The development process in the software life cycle involves 4 phases.

Analysis

• Define the user (generic or specific?)

• Define the needs (expectations)

• Define the requirements

• Define the methods (to meet requirements)

Design phase

• The design phase defines how the system will accomplish what was defined in the analysis phase.

• Modularity

• Tools– Structure chart– UML

Implementation phase

• Tools– Flow chart– Pseudocode

• Coding

Testing phase

• Black box tesing– Black box test plans are developed by looking o

nly at the requirements statement.

• White box testing– White box testing is the responsibility of the pr

ogrammer, who knows exactly what is going on inside the program.

Development process models

• Waterfall model: a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing and Maintenance.

Development process models

• In the incremental model, the process is developed in a series of steps.

• First complete a simplified version of the whole package.

• Gradually add more details.

Modularity

• Modularity means breaking a large project into smaller parts that can be understood and handled easily.

• Tools– Structure chart– Class diagram– Unified Modeling Language (UML)

Modularity - coupling

• Coupling is a measure of how tightly two modules are bound to each other.

• Loose coupling is more desirable, because:– Independent functions are more resuable– Less likely to cause problems– Maintenance modifications are easier

Modularity - coupling

• Data coupling: passes only the minimum required data from the calling function to the called function. Most desirable.

• Stamp coupling: when the parameters are composite objects such as arrays.

• Control coupling: passes flags to direct the control flow of a function.

• Global coupling: uses global variables. Should never be used.

• Content coupling: when one function refers directly to the data or statements in another function.

Modularity - cohesion

• Cohesion is a measure of how closely the processes in a program are related.

• Function cohesion: A module with function cohesion contain only one process. For example, in printing a report, the report function should call 3 lower level functions: one to get the data, one to format and print the report header, and one to format and print the data.– Only one thing

– In one place

Modularity - cohesion

• Sequential cohesion: A module with sequential cohesion contains two or more related tasks that are closely tied together, usually with the output of one flowing as input to the other.

• Example: the calculations for a sale:– Extend item prices

– Sum items

– Calculate sales tax

– Calculate total

Modularity - cohesion• Communicational cohesion: It combines processes

that work on the same data. • Example: a function that reads an inventory file, p

rints the current status of the parts, and then checks to see if any parts need to be ordered.

• The first 3 levels of cohesion are all considered good structured programming principles.

• Beyond this point, ease of understanding and implementation, maintanability, and accuracy begin to drop rapidly.

Modularity - cohesion

• The 4th level, procedural cohesion, combines unrelated processes that are linked by a control flow.

• The 5th level, temporal cohesion, combines unrelated processes that always occur together.

• The last 2 levels are seldom found in programs today. Logical cohesion combines processes that are related only by the entity that controls them. Coincidental cohesion combines processes that are unrelated.

Quality defined

• Quality software is defined as:– Software that satisfies the users’ explicit and implicit re

quirements, is well documented, meets the operating standards of the organization, and runs efficiently on the hardware for which it was developed.

• If you want to attain it, you have to be able to measure it.

• Whenever possible, these measurements hould be quantitative. For example: # of errors per thousand lines of code, the mean time between failures for software systems.

Quality factors

Operability

• Accuracy can be measured by such metrics as mean time between failures, number of bugs per thousand lines of code, and number of user request for change.

• Efficiency is, by and large, a subjective term. In some cases, the user will specify a performance standard, such as a real-time response that must be received within 1 second 95 percent of the time.

• Reliability is really the sum of the other factors.

Operability• Security: How secure a system is refers to how eas

y it is for unauthorized persons to get at the system’s data.

• Timelyness: Can mean different things, such as “Does the system deliver its output in a timely fashion?” or “Does the response time satisfy the users’ requirements?”.

• Usability: Highly subjective. The best measure is to watch the users and see how they are using the system.

Maintainability• Maintainability refers to keeping a system running

correctly and up to date.• Changeability: how easy is it to change a system?• Correctability: one measure of correctability is me

an time to recovery, which is the time it takes to get a program back in operation after it fails.

• Flexibility: is a aualitative attribute that attempts to measure how easy it is to make these changes.

• Testability: how easy is it to test the system? Are complex structures employed in the code? Does the detailed design contain clear pseudo-code?

Transferability

• Transferability refers to the ability to move data and/or a system from one platform to another and to reuse code.

• Code reusability: is the likelihood a segment of structured code can be used again to add new functionalities with slight or no modification.

• Interoperability: is the ability of sending data to other systems.

• Portability: is the ability to move software from one hardware platform to another.

The quality circle

The quality circle

• There are 6 steps to quality software: quality tools, techincal reviews, formal testing, change controls, standards, and measurement and reporting.

• Software engineers need quality tools to develop a quality product.

• Technical review should be conducted at every step in the development process, including requirements, design, programming, and testing.

The quality circle

• Formal testing ensures that the programs work together as a system and meet the defined requirements.

• To ensure quality, each change should be reviewed and approved by a change control board.

• A good quality environment measures all aspects of quality and regularly reports the results.

• At the same time, published standards provide the yardstick for many quality measurements.

Documentation

• User documentation: traditionally called a manual, user documentation shows how to use the package step by step. – A good user manual can be a very powerful ma

rketing tool.

• System documentaion defines the package itself.

System documentation

• Documentation in the analysis phase.– Info collected should be carefully documented.– Analyst should define the source of info.– Requirements and methods chosen must be clea

rly stated with the rationale behind them.

System documentation

• Documentation in the design phase.– Tools used in the final copy must be documente

d.– For example, if a structural chart undergoes sev

eral changes, the final copy should be documented with complete explanations.

System documentation

• Documentation in the implementation phase.– Every tool and every program should be docum

ented.– The program should be self-documented.– Two levels of program documentation:

• General documentation: each program should start with a general description of the program, then the name of the author and the date, then change history.

• Function documentation: whenever necessary, brief comment for blocks of code should be added.

System documentation

• Documentation in the testing phase.– Each type of test applied to the final product sh

ould be mentioned along with the result.– Even unfavorable results and the data that prod

uced them must be documented.

• Documentation as an ongoing process.– If the package has problems after release,…– If the package is modified, …– Documentation stops when the package become

s obsolete.

Objectives

• Understand the software life cycle.

• Describe the development process models..

• Understand the concept of modularity in software engineering.

• Understand the importance of quality in software engineering.

• Understand the role of documentation in software engineering.