software engineering lecture notes section a

7/28/2019 Software Engineering Lecture Notes Section A

1/10

Page 1

ADVANCED DIPLOMA

TELECOMMUNICATION SYSTEMS SOFTWARE ENGINEERING

2730-03-025

IntroductionThe-aim of this unit is to enable the candidate to:a) Demonstrate a high level of competency in the creation of a computer programmeb) manage and document a software development.Notes:1 It is suggested that about 150 guided learning hours should he given to this unit.2 It is recommended that the guided learning hours should be allocated as follows:

The need for software engineering software process 7 hours Software specification requirements analysis 20 hours

Software design and implementation design methodology 12 hours

Programming practice and software tools 22 hours

Software validation testing 18 hours

Programming languages 56 hours

Book listThe Formal Semantics of Programming Languages; Glynn Winskel.Object-Oriented Software Engineering; Ivar Jacobson.1Ill and MySQL Web Development; Luke Welling, Laura Thompson.A Programmers Guide to Software Development (2nd edition); Keith Ilaviland, Dma Gray, Ben Salama,Gina Gray.

The Structure of Typed Programming Languages; David A. Schmidt.

Practical competencesThe candidate must he able to:1.1 Design and implement a software solution.1.2 Plan, manage and fully document the development process of a software solution.1.3 Access sources of reference accurately.


2/10

Page 2

CHAPTER 1: THE NEED FOR SOFTWARE ENGINEERING SOFTWARE PROCESS

1.4 Describe the term software crisis.

Software crisis- Refers to the impact of rapid increases in computing power and the complexity of the problems

which need to be solved using the computer

- hence it refers to the difficulty of writing correct, understandable, and verifiable computer programs

under those complexities of ever changing computer technology and user requirements andspecifications

- The roots of the software crisis are complexity, expectations, and change.

1.5 Describe the problems associated with large scale software development.- Conflicting requirements: - while users demand a large number of features, customers generally

want to minimize the amount they must pay for the software and the time required for its

development.

- Computer machines are ever changing and becoming more powerful by very large magnitude hence

the expectations of what they can do keep rising, hence software requirements keep changing and

become more complex.

- In general, software projects which are large, complicated, poorly-specified, and involve unfamiliar

aspects, and unanticipated problems are the major problems associated with large scale softwareo Failure to follow an acceptable approach to system development

o

Inadequate commitment of top managemento Inadequate involvement of users

o Inexperienced project managero Unclear objectives

o Failure to identify project risks

o Inadequate control system to manage project risks

o Mismanagement of suppliers and consultants

Failures that result are:o Project is abandoned (not delivered)

o Project is delivered late.

o Project cost exceeds approved budget.o The delivered system lacks required functions.

o The delivered system does not meet performance standards.

o The system is not user friendly.

o

The system is unreliable / fails frequently during operation.o The system is not integrated with other systems.

o The system is difficult and costly to maintain.

o The system is not flexible enough to take care of future requirements.

o The system is costly to enhance

1.6 Describe, with the aid of a diagram, the waterfall model of software developmenti) specification/requirements analysisii) designiii) implementationiv) testingv) maintenance

Software lifecycle

-

Software life cycle refers to the time when the software is conceived as an idea through to itsspecifications, design, implementation, testing, and maintenance and then degeneration to

extinction

The waterfall model- Is 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 and

validation, Construction, Testing and maintenance.


3/10

Page 3

IDENTIFICATION OF A PROBLEM- Find out if the problem really exists or otherwise users are ignorant of some function on the existing

system only

- If it does exist, then write the problem in technical terms such that items of the problem are clearlyvisible.

- spell out the aims and objectives of new system

cost reductions,

better service to customers;

greater volume of business transactions

NB All the test and reviews of the system will be comparing the results with these objectives to determine

the correct operation and effectiveness of the solution

1. FEASIBILITY STUDY-

Feasibility study is a preliminary investigation that is used to essentially determine whether a project is

technically and economically possible and viable- Determines if the possible solutions is not beyond the current means : - resources, money and time

- Determines if the new solution is technically achievable and appropriate given existing conditions

- Determine if the projects can be suitably solved by computer solution or not

- Determines if :

technology is currently available to solve the problem

it is socially feasible - will there be a need for redundancies, retraining?

it would be cost effective development costs and running costs against benefits such as

reduced operational costs, better customer service etc

A written report may be presented to management for a decision on whether to proceed.

Specification/ Requirement Analysis

Design and Development

Implementation

Testing

Maintenance


4/10

Page 4

2. INFORMATION COLLECTION- Collection of inputs for the project so that the design is streamlined to deal with the appropriate

information. This stage may involve:

questionnairesguided question list to staff and management;

structured interview personal meetings with staff and management;

observation -personal involvement in procedures (invoicing, accounting, use of network etc)

documents collection of documents, manuals, records, forms, reports, booklets or books etc

3. REQUIREMENTS ANALYSIS- Deriving the technical meaning contained in the data gathered

- Determining the requirements i.e. what exactly, technically needs to be designed

- Determine or come up with the specifications of the system to be design

Analysis of present system to determine its inefficiencies and problems

Determine the requirements of the new system

o Based on what the user requires

o Hence determine Hardware and Software required

o theoretical arrangement / configuration of hardware /software

An overall picture of the main tasks to be drawn to showo the sequenced tasks

o

Data flowing into and out of the system - data flow diagrams and system flow charts Come up with a with clearly written system requirements and identifiable tasks

List of requirement document called URS User Requirement Specification - the success of thenew system will be judged by whether it meets all these requirements listed in the URS

4. DESIGN- The purpose of the design stage is to draw and draft a working solution to meet the requirement specified

in the URS document of the previous stage

- The actual work of creating solution based on the findings is performed

- This involves the following

Input sketch and specification of screens layout of forms and dialogue boxes and input data

Output contents, data format, data sequence, data frequency, sound, video, graph, receipts etc

Files contents records layout, organization and access method, data dictionary definitions etc

Processing

programs, procedures and their detailed design

Security prevention of accidental and deliberate deletion or corruption and also tempering and

hacking

Testing strategies design of methods of test that are need to be done when the system is

developed later

Hardware configuration selection of appropriate operation mode and configuration

Data capture forms must be designed, clerical procedures laid down and all aspects of the design

must be documented.Output of this stage is a document called the Design Specification document

5. DEVELOPEMENT AND TESTING- Development Project Design Specification document is given to programmers who would then code

the program modules/tasks , test anddebug

-

Testing - The new system is put to test according to the test strategy designed and specified during thedesign stage. A good test strategy will eliminate prolonged future problems.

- Development and testing involve -tailoring the package or environment where the project runs

- Implementing screen designs- Reports

- Macros- Creating the actual data storage files

- Acceptance test customer acceptance testing


5/10

Page 5

6. IMPLEMENTATION- Implementation of the designed system

- Installing and testing the overall system

- Staff training- Changing over to the new system is often done by:

parallel-running the new system with the old one until fully operational

Direct changeover

Pilot

7. MAINTENANCE OF THE SYSTEMAll systems need to be maintained - making sure the system continues to function correctly,

modifications made, errors corrected, documentation kept up-to-date.

8. OBSOLESCENCEAll systems reach their pick and decline until they are surpassed, by new products which come with change

in technology. The system will be archived and finally be completely removed.

Feasibility study

Tasks Activity

Investigation of old system Give a analysis reports on existing system

Specification of objective of new system -Cost reduction,

-better service to customers,-better management of information,-high volume of business

Passing/failing new system Establish whether new system will achieve objectives

or not and report on whether it is worthy trying

Proposal of solution Identify the most suitable system to achieve objective of

the new system e.g. programming, database,

spreadsheet, etc

Effectiveness of solution Produce a cost-benefit analysis report

Implementation schedule Produce a plan for implementing the new system with

details of duration (time)

Cost benefit analysis

Item Cost (disadvantage) Benefit (advantage)

New equipment (computers, printers,

etc)

Purchase price New asserts into the organization

Renovations (buildings, wiring, air

conditioners etc)

Installation cost Lasting structural asserts

Development of new product (system

analysis, design, new solution software

purchase, change over cost)

Development cost New lasting software assert , high staff

moral associated,

Staffing (training, recruitments, salaries,

redundancies

Personnel costs

-training cost-recruitment costs

-retrenchment costs

Improved personnel quality

- better skills- new productive team

- removal of redundancy

Operation consumables, maintenance,

insurance, standby etc

Operating costs New system is often an improvement of

the old one such that operation costs will

be lower

Improvements Improved

- cash-flow

- stock control

- staff moral

- management of information

- customer service

- extra sales


6/10

Page 6

INFORMATION COLLECTIONIn information gathering helps to know exactly the technical requirements of the system before the system

design begins.

Tasks Target Activity

Interviews Clerical staff, users, management

technical team, customers etc

Opinion, facts, insight of operation,

identification of problem area

Questionnaire Large number of people in a

population

To get statistical average of preferences on

available options.

Observation Personal in-depth knowledge Read books, manuals, documents, researchmaterial on how things work, current

technological trends, expert

recommendations, how design objectives are

achieved

1.7 STATE THE IMPORTANCE OF DOCUMENTATION

Documentation is the stage where all recordings of whatever sort are all gather up and all pieces of

information relating to the project are assembled into a helpful book/ booklet(s) or any other form of media

recording that will be used as a source of reference for both the user and the technical staff who particularly

may need to upgrade and maintain the system in the future.

Documentation is done during all the stages of product development but is considered specifically at the

end to perfect the details into a single document or set of documents or booklets.Mostly two types of booklets are produced namely,

User manual

o How to install the systemo How the system should be used

o Details of features it offers

o How it should be maintained

o What to do in case of faults i.e. troubleshooting

o examples of output screens

o examples of valid input

o methods of input of data

Technical manual

o How the system was produced technically

o How the system can be modified and upgraded

o Flow charts, data flow diagrams etc

Technical, documentation:

It is also called the maintenance documentation.

The technical documentation will include the program specifications, the coded program itself, details of

hardware configurations. It must include record, file, data structures, data dictionary, dataflow diagram,

detail system flowcharts, program listings with proper annotations, various pseudo code algorithms

used, including the formula used in the project.

Hardware and software details should be explained in detail

User Documentation

Should be more user friendly, It includes the various screen displays, printing options, back up procedures,

security features and a proper guidance during errors and lastly installation procedures

Technical documentation

The technical documentation will include the program specifications, the coded program itself, details of

hardware configurations. Generally, anything that will aid a technician in maintaining or updating a system.

Indeed, technical documentation is otherwise known as maintenance documentation. This type of

documentation is not intended to be accessible to the user of the system, who does not need any of thesedetails to be able to use the system correctly.


7/10

Page 7

Class Exercise

1. a) Describe what is meant by the term software crisis [3]

b) List and explain three problems associated with large scale software [7]

2. a) Briefly describe the following stages of software developmenti) Specificationii) Requirement analysis

iii) Designiv) Implementationv) Testing

vi) Maintenance [6]b) Show with the aid of a waterfall diagram how the above stages are related [4]

There are four major threats to successfully building large-scale software-intensive systems:

(1) a failure to control the complexity that arises during the development process(2) a failure to achieve early resolution of deficiencies in informal statements/knowledge of

stakeholders' needs

(3) failure to construct a system that satisfies customers needs, and

(4) A failure to effectively organize the project team.

All four of these threats can be very significantly reduced by making maximum and effective use of the

requirements information that expresses customers needs. This is achieved by choosing a representation

that supports rigorous formalization and composition of individual requirements one at a time into an

integrated, state-based, graphical view. It amounts to building a system 'out of' its requirements. The

justification for, the processes, representations and results of applying this constructive approach to tackling

the core problems associated with developing large-scale, dependable systems is presented.

Summary of stagesStage Details Deliverable Tools Person

Analysis It consists of

description or a list ofuser's requirements

Requirements

Specification SystemSpecification

Use Case,

SystemSpecification,

Systems Analyst

Business Analyst

Design It consists of thingssuch as Architectural

Diagram, Data FlowDiagram, System

Flowchart, DataDictionary, Database

Scheme, entity

relations

Design Specification,Functional

Specification,Systems Interface

Specification

SequenceDiagram Class

Diagram

Systems Analyst, Architect

Development Program Specification

which consists ofProgram Flowchart,

Truth Table, DecisionChart,

Detail software

Design, Source code(Detailed Level)

Code Class

DiagramMessage

SequenceDiagram

Systems Analyst,

Programmer, Developer

Testing Test Case, TestSummary Report

Test ExecutionRecord,

Test Analyst

Implementation Deployment Model Implementation

StrategyDeployment Plan

Systems Analyst, Business

Analyst, Architect, ProjectManager Development team

Review Post Implementation

Review Report,

Initiatives for nextmaintenance project

Project Manager


8/10

Page 8

CHAPTER 2: SOFTWARE SPECIFICATION REQUIREMENTS ANALYSIS

1.8 DISTINGUISH BETWEEN REQUIREMENTS DEFINITION AS A USER VIEW OF THESYSTEM AND REQUIREMENTS SPECIFICATION AS A FORMAL TECHNICAL VIEW.

User requirement definition- The user specifies the system that he wants or expects, mostly in non technical terms- The user sees the system as a black box and realises system specifications in terms of

input and output that are tangible from his/her business perspective in most casesExample of user specification

Item Details know by user

Website To sale products

Advertisement online

Goods display online

Payment on line

Tracking of order processing online

Delivery details onlineCompany Logo

output Goods layout on screen

Input Search required

report Printouts

Requirement specification (formal technical view)Formal specificationis the expression of a system to be designed using structured language terms with

precise, standardized, unambiguous wording and system models diagrams to imply or represent the correct

framework or architecture of the intended design. Steps involved are

(a) High-level goals are identified and refined until a set of requirements on the software and assumptionson the environment can be made precise to satisfy such goals;

(b) A software architecture, made of interconnected software components, is designed to satisfy such

requirements;

(c) The various components are implemented and integrated so as to satisfy the architectural descriptions.

- The designer or system analyst defines the system in technical details to show all or most

of the technical aspect of the system precisely- The designer has a white box or transparent view of the system seeing all aspects of

operation and design parametersExample of formal technical view specification

Item Details

Website To sale products

Input Data types and fields

Form design specification

Processing Data flow Diagrams logical flow of dataSorting, tracking records and storage

Software PHP, Java script, Html

Database

Hardware Logical connection and configurationHardware detailed specs

Performance Download speed, processing efficiency

Link details

output Output report print out specificationThe system being specified may be a descriptive model of the area of interest; prescriptive model of the

software and its environment; prescriptive model of the software alone; a model for the user interface; the

software architecture; a model of some process to be followed;

The properties under consideration may be

- functional requirements;


9/10

Page 9

- non-functional requirements about timing, performance, accuracy, security, environmentalassumptions; services provided by architectural components; protocols of interaction etc

1.9 DISCUSS WHY BOTH SYSTEM VIEWS OUTLINED IN 1.8 ARE NEEDED.

User spec gives the- main aim skeletal requirement articulation from which the aims and objectives of the

system are derived- User expectation are clarified and tie the user to the system (makes it his/her system)

-Acceptance of the system largely depends on how the user views the designed systemand on whether the design meets these expectations

Technical formal Requirement specificationAformalspecification if is expressed in a language made of three components:

- rules for determining the grammatical well-structured-ness of sentences (the syntax);

- rules for interpreting sentences in a precise, meaningful way within the domain considered (thesemantics);

- and rules for inferring useful information from the specification (the proof theory).Formal specification is necessary for

- Writing a correct specification

- Providing specification that is adequate, i.e. it must adequately state the problem at hand. It must beinternally consistent, that is, it must have a meaningful semantic interpretation that makes true allspecified properties taken together.

-It must be unambiguous, that is, it may not have multiple interpretations of interest making it true.

- It must be complete with respect to higher level ones, that is, the collection of properties specifiedmust be sufficient to establish the latter

- It should be minimal, that is, it should not state properties that are irrelevant to the problem or thatare only relevant to a solution for that problem

Problem specifications are essential for designing, validating, documenting, communicating,

reengineering, and reusing solutions.

Formalization helps in obtaining higher-quality specifications within such processes;

It also provides the basis for their automated support.

Formalization raises many questions and detect serious problems in original informal formulations.

Besides, the semantics of the formalism being used provides precise rules of interpretation that allow many

of the problems with natural language to be overcome. A language with rich structuring facilities may also

produce better structured specifications.Formal specifications may be manipulated by automated tools for a wide variety of purposes:

to derive premises or logical consequences of the specification, for user confirmation, through

deductive theorem proving techniques

to confirm that an operational specification satisfies more abstract specifications, or to generate

behavioral counterexamples if not, through algorithmic model checking techniques

to generate counterexamples to claims about a declarative specification

to generate concrete scenarios illustrating desired or undesired features about the specification or,conversely, to infer the specification inductively from such scenarios;

to produce animations of the specification in order to check its adequacy

to check specific forms of specification consistency/completeness efficiently

to generate high-level exceptions and conflict preconditions that may make the specificationunsatisfiable

to generate higher-level specifications such as invariants or conditions for liveness

to drive refinements of the specification and generate proof obligations;

to generate test cases and oracles from the specification

to support formal reuse of components through specification matching

Formal specifications can also be generated from program code as a basis for reverse engineering

and software evolution


10/10

Page

10

1.10 DESCRIBE THE CONCEPT OF SYSTEMS MODELLING.- It is all about representing, communicating, presenting, demonstrating the structure a system in a

way that enables the system features to be revealed through the portrayed representation

- It is an abstract descriptions of systems whose requirements are being analyzed

- It is a formal method a techniques and notations for the unambiguous specification of software

- Software modeling helps the engineer to understand the functionality of the system

- Models are used for communication among stakeholders and are centered on diagrammatical formalpresentation of a system, typically using notations such as in the Unified Modelling Language(UML)

-

Different models present the system from different perspectives External perspective showing the systems context or environment Process models showing the system development process as well as activities

supported by the system Behavioural perspective showing the behaviour of the system Structural perspective showing the system or data architecture

UML modelling systems diagrams are classified as1. Use case 2. Class diagram shows classes in the system3. Object diagram shows objects in the system4. Component diagram - shows components of the system (software packages/modules)5. Deployment diagram - shows deployment of the system at run time and all processes6. Activity diagram - shows activities in the system

7.

Statechart diagram shows different states of the objects in a the system8. Collaboration diagram - shows collaboration between the system objects9. Sequence diagram shows the time sequence of an object in the system

We will describe diagrams used in modelling1. Dataflow diagrams2. Entity Relationship3. Use case

Data flow diagrams of course registration for modelling a business

- Student application is brought to the system

Student is an external Entity that brings data to the system- System software checks for course availability

It searches from the courses file

It transfers or saves student application details into applications file- System process number 2 checks the students qualifications

Acceptance/Decline

Reply

Inquiry

Application details

Reply

InquiryApplication

1

Check course availability

2Check applicant

qualifications

STUDENT

Applications

Courses

software engineering lecture notes section a

Documents