Software Engineering students module, Lecture notes of Software Engineering

Download Software Engineering students module and more Lecture notes Software Engineering in PDF only on Docsity!

Software Engineering Manual i

DEPARTMENT OF PURE AND APPLIED

SCIENCES

BBIT 3101

UNIT: SOFTWARE ENGINEERING

Software Engineering Manual ii

CHAPTER 1: FUNDAMENTALS OF SOFTWARE

ENGINEERING

Chapter Objectives

At the end of this chapter, student should understand:

1. The Evolution of Software and the Software Crisis
2. Concepts of Software Engineering
3. Skills necessary for Software Engineering
4. Software Engineering Components: o Methods, o Tools and Procedures
5. Software Engineering Paradigms o The Classical Life Cycle o Prototyping o Fourth Generation Techniques o Combination of Paradigms
6. Changing Nature of Software Development

1.1 The Evolution of Software

The Early Years (50's - mid 60's)

 This generation was characterized by Batch orientation, limited distribution, and customization of software.

 In Batch Processing, the system handles an entire sequence of jobs together, often with little or no human intervention.

 Also, as computers were not widely used at that time, only in scientific and military institutions, software could be highly customized since distribution was limited. Job mobility was low, and the software was basically designed this way: You wrote it, you got it working, and if it failed, you'll be the one to get it working again.

Second Era (60's - mid 70's)

 This era saw the growth of software houses and the use of multiprogramming and multi-user systems, introducing with it new concepts of human-machine interaction.

 Software started to be distributed in a multidisciplinary market. At this point of time, the software crisis began.

Third Era (70's - mid 80's)

 This period was characterized by widespread growth and the use of personal computers.

 Similarly, the use of microprocessors saw its way into use of intelligent products.

 This led to the greatly increased usage of software and subsequent mushrooming of software companies.

Fourth Era (80's and beyond)

 This period saw the use of increasingly powerful desktop systems, object-oriented technologies, Expert Systems, Artificial neural networks, and Parallel Computing.

 The software crisis intensifies!

Software

Engineering

Methods Tools^ Procedures

 Methods: these are the how-to for building the software. Examples of these are (I) Project Planning; (2) System and Software requirement analysis; (3) Coding, testing and maintenance.

 Tools: these are the automated or semi-automated support for methods. Examples of these are CASE, or Computer-Aided-Software-Engineering, the software equivalent of hardware design.

 Procedures: this is the glue that holds the methods and tools together. It defines the sequence in which methods are applied, and makes sure that the development of software is logical (i.e. flows in correct order) and is on time too.

 Software Engineering thus comprises of a set of steps that encompass each of the three elements above. These steps are often referred to as Software Engineering Paradigms. Four such paradigms are of interest to us:  Classical Life Cycle  Prototyping

 Fourth Generation Techniques  A combination of all three techniques

1.3.1 The Classic Life Cycle

Also known as the Waterfall model, this life-cycle paradigm demands a systematic and sequential approach to software development. It presents a highly structured method of software development that starts at the system level, and progresses through analysis, design, coding, testing and finally maintenance.

Systems Engineering

Analysis

Testing

Maintenance

Design

Coding

 Systems engineering: establish requirements for all system elements and then allocating some subset of these requirements to software. Essential for interfacing correctly with external components, e.g. databases, hardware

 Analysis: analysis of requirements is now focused on software alone. Requirements for both system and the software are documented and reviewed with the customer.

 Design: the multi-step process that focuses on four distinctive attributes of the program: (a) data structures; (b) software architecture; (3) Procedural detail; (4) Interface characteristics.

 Coding: design is translated to machine readable form

 Testing: focuses on the logical internals of the software.

 Maintenance: errors/changes will invariably occur because software must accommodate changes in the real and external environment.

 Common problems faced with the Classic Life-Cycle

 Real projects rarely follow sequential flow of the "waterfall" model, i.e. they jump to-and-fro. And iterations by itself always produces problems.  It is difficult to determine requirements so explicitly and so early in the development. There is always a lot of uncertainty at the start of the project.  The customer has to wait for a really long time before he even gets a feel of the real project, i.e. working version of prototype is not available early in the cycle.

 Despite these problems, the Classic Life-Cycle still remains the most widely used procedural model for software engineering.

1.3.2 Prototyping Paradigm

 It often happens in a typical software development cycle that the customer has defined a set of general objectives for software, when much more detailed input, processing, or output requirements are needed by the software developer. Or that the developer could be unsure of the efficiency of an algorithm, the adaptability

A possible solution to this problem then is that the software developer and customer must both agree that the prototype is only meant to define requirements. It is then discarded and actual software is engineered with an eye towards quality and maintainability.

1.3.4 Fourth Generation Techniques

 4th Generation Techniques actually encompasses a broad array of software tools which have one thing in common: each of them enables the software developer to specify some characteristic of software at a high level. The tool then automatically generates source code based on the developer specification. One of the special characteristics about this technique is that the high level language used is often very close to our natural language.  Features of 4L Tools:  Database Query

 Report Generation  Data Manipulation  Screen Interaction  Code Generation  Graphics/Spreadsheets

 Requirements Gathering. Ideally, the customer could actually describe the requirements and these would be directly translated into an operational prototype. However, this is generally unworkable, since the customer may be unsure of what exactly is required, or introduce a degree of ambiguity in these requirements.  Design Strategy. Often, for smaller scale software applications, it is possible to move directly from the requirements gathering step to implementation using a non-procedural 4th Generation Language. However, for large projects, the design phase is crucial to avoid poor quality, poor maintainability, and poor customer acceptance problems later.  Implementation Using 4GL.

 Product  Possible Problems faced in 4GT

 Current Application domain for 4GT is limited to business information systems, for example information analysis and reporting that is keyed to large databases.  Rapid system development is true only for small systems

Requirements Gathering

Design Strategy

Implementation

Product/ software deliverable

Changeover/ maintenance/Revie w

 4GTs are not substitutes for good design planning necessary particularly for large software development efforts.

1.3.5 Combining Paradigms

 In many cases, paradigms can be combined and the strengths of each can be utilized in a single project. By looking at the diagram, requirements gathering is still essential, and interaction between the developer and customer must still occur. To create the prototype, 4GL can be applied to develop the prototype quickly. Once the prototype has been evaluated and refined, the design and implementation steps of the classic life cycle can be applied to engineer the software formally.

Engineer

Prototyping

Requirements

Gathering

Classic Life

Cycle

Apply 4GL Prototype

1.4 The Changing Nature of Software Development

 In the graph, a number of observations can be seen:

 The overall demand for software will continue to rise in the future.  However, the ratio of software products developed using conventional methods and 4th generation methods will change.

Chapter Review Questions

CHAPTER 2: REQUIREMENTS ANALYSIS

FUNDAMENTALS

Chapter Objectives

At the end of this chapter, student should understand: to :

 Requirement Analysis

 Analysis Tasks

 Problem Recognition  Evaluation and Synthesis  Modeling  Specification  Review

 The Analyst  Problems in Requirement Analysis  Communication Techniques  Preliminary Meeting or interview  Facilitated Application Specification Technique (FAST)

 Analysis Principles  Information Domain  Partitioning  Essential and Implementation Views

2.1 Requirements Analysis

A formal definition for Requirements Analysis would be:

 Requirements Analysis the process of discovering, refinement, modeling and specification in a software project.

 Such a process will always involve both the customer and system engineer, allowing the system engineer to:

 Specify software function and performance;  Indicate softwares interface with other system elements;

 Establish design constraints that the software must meet.The three points above can also be thought of as the objectives of Requirements Analysis

 Requirement Analysis provides the software designer with a representation of information and function that can be translated to data, architectural and procedural design.

 Finally, Requirement Analysis is also concerned with the preparation of the Software Specification, a formal document that specifies clearly the functional and performance requirements of the software. This Specification document in turn will allow the developer and customer to assess quality once the software itself has been built.

 The software developer performing Requirement analysis would often be known as the analyst.

2.2 Analysis Tasks

 Software requirement analysis can be divided into an ordered sequence of five main areas of effort, namely:

 Problem Recognition  Evaluation and Synthesis  Modeling  Specification  Review

 Problem Recognition

 Goal of analyst here is recognition of the basic problem elements as perceived by user and customer

 Understand software in the system context  Define software scope  Analyst will also need to establish contact with management and technical staff of the customer and software development organization

 Evaluation and Synthesis

 The analyst must now evaluate the flow and content of information  Define and elaborate all software functions  Understand software behavior in the context of events that affect the system;

 Establish system interface characteristics;  and uncover design constraints.  Throughout this step, the emphasis is on what must be done, not how it will be done.  This step will continue until both the analyst and customer feels confident that software can be adequately specified for subsequent development steps. 

 Modeling

 The analyst will then create models of the system that will enable better understanding of data and control flow.  These models describe the data and control flow, functional processing, behavioral operation, and information content.  Models serve a number of important roles:

• Aids in understanding the information, function and behavior of a system.
• Makes requirement analysis task easier and more systematic
• It serves as a basis for creating specification for the software.
• Becomes the focal point for review.
• Becomes the foundation for design.

 Specification

 The Specification document is now developed.  The specification is a representation of software that can be reviewed and approved by the customer.  Usually developed as a joint effort between the developer and the customer.

2.3 The Analyst

 The basic responsibility of the analyst can be said to be the following:

 To analyse and define systems of optimum performance, i.e. an output that fully meets management objectives

 The analyst must also exhibit the ability to:

 Grasp abstract concept, partition them and generate solutions based on each division  Understand implicit information, separate them and treat them individually

 Absorb pertinent facts from conflicting sources  Understand the customer environment  Apply hardware and/or software system elements to the customer environment  Communicate well in written and verbal form

2.4 Problems in Requirements Analysis

 Requirements analysis is a communication-intensive activity. i.e. where communication is concerned, noise, i.e. miscommunication, will always occur.

 Thus problems like miscommunication and omission often occur between analyst and customer. This is often because of different levels of communication between an analyst and customer.

 Successful acquisition of information cannot be guaranteed. This is because when communication fails, information can be wrongly put forward, and misinformation then occurs. And we know that accurate requirements analysis is highly dependent on getting the correct information.

 Analyst have difficulties:

 In getting pertinent (appropriate) information  Handling large and complex problems, i.e. as complexity increases, effort increases  Accommodating changes that occur during and after analysis

2.4.1 Causes for the Problems

 Poor communication that makes information acquisition difficult  Inadequate techniques and tools for developing specification

 Tendency to take short-cuts during requirements analysis tasks, leading to unstable design  Failure to consider alternative solutions before software is specified on both parts of analyst and customer. i.e. are there better ways to do this?

2.5 Communication Techniques

 Because of these problems, Requirements Analyze must be concerned with how to address these problems. There are two techniques that are available to tackle these problems:  Preliminary meeting or interview  Facilitated Application Specification Technique (FAST)

2.5.1 Preliminary Meeting or Interview

 Proposed by Gause and Weinberg  The most commonly used analysis technique to bridge the communication gap between the customer and developer. Though effective for a first meeting, it should not be used for subsequent meetings between the customer and software developer.  The technique comprises of 3 different sets of questions

First Set  These questions should lead to a basic understanding of the problem  Focuses on the customer and overall goals and benefits. Second Set  These questions should enable the analyst to gain a better picture of the problem.

 Allow the customer to voice his/her perceptions about a solution. Third Set  Focuses on the effectiveness of the meeting itself.

2.5.2 FAST (Facilitated Application Specification Techniques)

 This can be thought of a technique that is used after the first meeting is completed and basic understanding has been achieved. It proposes a meeting format that combines elements of problem solving, negotiation, and specification.

 The FAST mentality encourages the working together mentality rather than working individually. Hence, the technique is always a team-oriented approach, the team jointly made up of customers and developers.  The basic goals of the FAST meeting are:  Identify the problem  Propose elements of the solution

 Negotiate different approaches  Specify a preliminary set of solution requirements.  There are different approaches to FAST, but all of them have the following basic guidelines:

 Meeting is conducted at a neutral site;  Rules for preparation and participation are established;  An agenda is suggested to cover all the important points. Agenda must be formal enough to cover all important points, but informal enough to encourage the free flow of ideas.  A "facilitator" is appointed to control the meeting. A facilitator is the controller, overall chairman of the meeting.

2.6 Analysis Principles

 Over the years of software development, a number of analysis and specification methods have been developed. But analysis methods are related by a set of fundamental principles:  The information domain of a problem must be represented and understood;  Models that depict system information, function, and behavior should be developed;  The models (and the problem) must be partitioned in a manner that uncovers detail in a layered (or hierarchical fashion);  The analysis process should move from essential information toward implementation detail.

 The Information Domain

 The information domain contains three different views of the data and control as a processed by a computer system, namely: (1) Information Flow; (2) Information Content; (3) Information Structure. Information Flow  Represents the manner in which data and control change as each moves through a system

 Implementation view presents the real world manifestation of processing functions and information structures.  Concerned with the physical how-is-it-going-to-be-done aspect.

Chapter Review Questions

1. outline the qualities of a good system analyst
2. Describe the various different types of non functional requirements which may be paced on a system. Give

examples of these requirements.

3. write a set of non functional requirements for a an examination management system
4. Suggest how a software engineer responsible for drawing up a system requirements specification might keep

track of the relationships between functional and non functional requirements of a system.

References for Further Reading

1. Kotonya.G and Somerville, I (1998), Requirements engineering: Processes and Techniques, Wiley.
2. Somerville Ian (2002) software engineering ,Pearson’s education

CHAPTER 3: REQUIREMENTS ANALYSIS METHODS

Chapter Objectives

At the end of this chapter, stdent should understand:: Requirement Analysis Methods

 Definition  Common characteristics in Requirement Analysis Methods

 Differences in Requirement Analysis Methods

Data Structure-Oriented Methods

 Data Structured Systems Development (DSSD)

 Jackson Systems Development (JSD)

Formal Methods

 Current status of Formal Methods  Attributes of Formal Specification Languages

 Case Study: A Formal Specification in Z  The Road Ahead of Formal Specification

Automated Techniques for Requirement Analysis

3.1 Requirements Analysis Methods

 Definition of Requirement Analysis Methods:

 Requirement analysis methods enable an analyst to apply fundamental analysis principles in a systematic fashion.

 Requirement analysis methods enable an analyst to apply fundamental analysis principles in a systematic fashion. But all methods share a number of fundamental and common characteristics. They:

 each supports the fundamental requirements analysis principles  each creates a hierarchical representation of a system  each demands a careful consideration of external and internal interfaces  each provides a foundation for the design and implementation steps that follow

3.1.1 Common Characteristics of Requirement Analysis Methods

Although each method introduces new notation and analysis heuristics, all methods can be evaluated in the context of the following common characteristics:  Mechanism for information domain analysis, i.e. all analysis methods addresses (either directly or indirectly) information flow, information content, and information structure.  Approach for functional and/or behavioral representations  All functions/behaviors are typically represented by specific notation.  Definition of interfaces

 Interfaces are derived from an examination of information flow.  Mechanisms for problem partitioning  Problem partitioning is accomplished by a layering process that allows for representation of information and function domain at different levels of abstraction.