Syllabus
SE & WT
Information gathering, requirement and feasibility analysis, data flow diagrams, process specifications, input/output design, process life cycle, planning and managing the project, design, coding, testing, implementation, maintenance. HTML, XML, basic concepts of clientserver computing.
th
th
th
Contents
SE & WT
Software Development
1 – 4
Software Development Life Cycle (SDLC)
4 – 5
The Software Requirements Document
5 – 7
Capability Maturity Model (CMM)
7 – 8
Qualities and Principles
8 – 12
Assignment 1
13 – 14
Assignment 2
14
Answer Keys
15
Explanations
15 – 16
Process Models
17 – 22
Design
22
Overview of Design
22 – 24
Varieties of Architecture
24 – 27
Module Design
27 – 28
Design Notations
28
Design Strategies
28 – 32
Object Oriented Design
32 – 38
Functional or Object Oriented?
38
Assignment 1
39 – 40
Assignment 2
40 – 41
Answer Keys
42
Explanations
42 – 43
th
th
th
Contents
SE & WT
Software Project Planning
44
Types of Project Plan
44
SPMP Document
45
Metrics for Project Size Estimation
45 – 47
Project Estimation Techniques
47 – 49
Project Scheduling
50 – 53
Risk
53 – 55
Reliability Metrics
55
Assignment 1
56 – 58
Assignment 2
59
Answer Keys
60
Explanations
60 – 62
Varieties of Testing
64 – 65
Designing Tests
65 – 71
McCabe’s Cyclomatic Complexity Number
71 – 72
Stages of Testing
72
Testing Strategies
72 – 73
Testing Procedures
73 – 75
Preparing Test Cases
75
Software Maturity Index
76
Coupling Metric
76 – 77
Client-Server Computing
77 – 78
Software Maintenance
78 - 81
Assignment 1
82 – 85
Assignment 2
85 – 86
Answer Keys
87
Explanations
87 – 89
th
th
th
Contents
SE & WT
HTML Header
91 – 95
HTML Body
95 – 97
Assignment 1
98 – 99
Assignment 2
99
Answer Keys
100
Explanations
100 – 101
Definitions
102
XML Anatomy
102 – 107
Creating a DTD (Document Type Defination)
107 – 109
Validating wih a DTD
109 –110
Assignment 1
111 – 112
Assignment 2
112 – 113
Answer Keys
114
Explanations
114 – 115
Test Questions
116 – 120
Answer
121
Explanations
121 – 123
Reference Books
124
th
th
th
Chapter 1
SE & WT
A software is a set of computer programs and it’s associated documentation. There are two fundamental types of software products: Generic and Customized. Are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. Are systems which are commissioned by a particular customer. Software engineering is defined as an engineering discipline that applies sound to scientific, mathematical, management and engineering principles to the successful building of large computer programs (software). Software engineering includes software requirements analysis; software design; implementation using modern programming methods; testing procedures; verification and validation; software configuration management; software quality assurance; tools for analysis and design; corporate software policies; strategies and goals; project management planning; organizing; staffing; directing and controlling; as well as the foundations of computer science.
Good software development organizations normally document all the information regarding the output to be produced at the end of different phases, methodologies to be adopted and so forth, into a coherent frame work called the organization’s organization’s software development model.
The Waterfall Model (WM) is an early WM is based on engineering practice; it works well if the requirements are well-understood and does not change — this rarely happens in practice. The Waterfall Model is important in the same sense as Newton’s Theory of Gravity: it’s wrong, but you can’t understand relativistic gravitation if you do not understand not understand Newtonian gravitation. WM is more of a theoretical way of developing software Classical WM model is structured as follows Feasibility Stud Requirement Analysis and Specification Design Coding and unit testing Integration and system testing Maintenance th
th
th
Chapter 1
SE & WT
(i) The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. Feasibility study involves the analysis of the problem and collection of all relevant information such as
Different data items which would be input to the system The processing required to be carried out on these data The output data required to be the produced by the system Constraints on the behavior of the system.
The collected data is analyzed to:
Obtain an abstract problem definition. Formulate different solution strategies Come out with alternative solution strategies to compare their benefits and short comings.
(ii) Write a Software Requirements Document (SRD) that describes in precise detail what the customer wants. Find out what the client wants. This should include what the software should do and also:
likely and possible enhancements platforms (machines, OS, programming language, etc) cost delivery schedule terms of warranty and maintenance user training
The IEEE standard suggests the following structure for SRD, also known as Software Requirements Specification (SRS) 1. Introduction 1.1 1.2 1.3 1.4 1.5
purpose of the requirements document Scope of the product Definitions, acronyms and abbreviations References Overview of the remainder of the document.
2. General description 2.1 2.2 2.3 2.4 2.5
Product perspective Product functions User characteristics General constrains Assumptions and dependencies.
3. Specific requirements cover functional, f unctional, non-functional and interface requirements. 4. Appendices
th
th
th
Chapter 1
SE & WT
5. Index The SRD does
say how the software works.
Major deliverable: SRD. (iii) The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document. Design documentation has three parts: An overall plan for the components of the system. The AD is sometimes called High-level Design Document (HDD). Description of the services provided by each software module. Description of how the module implements the services that it provides. In the AD, each module is a “black box”. The MIS describes each module as a black box. The IMD describes each module as a “clear box”. I n a black box, only the input/ output behavior is specified and the internal details are not known. Each requirement in SRD should be traceable to a feature in the design documents. Depending on the project and the requirements, it may be necessary to create a formal (mathematical) specification. Alternatively, selected critical parts of the system may be formally specified. Major deliverable: AD, MIS and IMD. (iv) Coding and unit testing phase is also known as the implementation phase of software development which is used to translate the s oftware design into source code. The end product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested t ested to determine the correct working of all individual modules. Major deliverable: source code and test results. (v) In this phase, the modules are integrated in a planned manner. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. When all the modules have been successfully integrated and tested, system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. There are three different kinds of testing activities:
∝ - testing: It is the system testing performed by the development team β – testing: It is the system testing performed by a friendly set of customers Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product.
th
th
th
Chapter 1
SE & WT
A system test plan document is to perform the system testing. It lists all the test cases and its expected outputs.
(vi) The product consists of all the documentation generated and well-commented source code.
Removing errors that were not discovered during the production development phase. This is called corrective maintenance for a new processor or OS or to new client requirements. This is called adaptive maintenance improving performance with respect to speed or space. This is called perfective maintenance. Maintenance taken up 60% to 80% of the total budget for typical industrial software. This implies the need for high quality work in the early stages. Good documentation and good coding practice make maintenance easier, cheaper and faster. is a rapidly growing field. Many companies have MLOCs of legacy code developed 20 or 30 years ago in old languages (e.g. COBOL, FORTRAN, PL/I) with little supporting documentation. documentation. Tools are used to determine how it works. Delivery also includes customer assistance in the form of manuals, tutorials, training sessions, response to complaints. The requirements of high quality product are the same as the requirements for maintainability. Maintenance is the solution, not the problem. (vii) Software tools are an important part of software development. The larger the project, the more important it is to use tools in its development.
Editor. Compiler and Linker Version control system (VCS) Software measurement (DATRIX) Specification checkers (OBJ3, Larch Prover) Test generators Graph editors for DFDs and other diagrams CASE tools for integrated development Browsers, library managers, etc.
SDLC is a model of a detailed plan on how to correct, develop, implement and eventually fold the software. It’s a complete plan outlining ou tlining how the software will be born, raised and eventually be retired and from its function. SDLC is often combined a subset of system development life cycle. There are several models for such processer, each describing approaches to a variety of tasks or activities that takes place during the process. Each phase of SDLC produces deliverable required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that th
th
th
Chapter 1
SE & WT
is driven by the design. Testing verifies the deliverable of the implementation phase against requirements. The various models will be discussed in the next chapter.
The SRD has a number of important functions. It provides the basis for:
agreement between customer and supplier. There may be other components of the agreement, such as legal documents. costing and scheduling. validation and verification. You cannot test software unless you know what it is supposed to do. all forms of maintenance.
A well-written SRD will reduce development effort by avoiding (expensive) changes later, in design and implementation phases. Notation: ■=
, ○ =
.
1. Functionality: What the S/W is supposed to do? 2. External interfaces: How does the S/W interface with people, systems hardware and other software 3. Performance: what is the speed, availability, response time and recovery time etc of various S/W functions? 4. Attributes: what are the considerations for portability, correctness, maintainability, security and reliability etc. since the SRC has a specific role to play in the S/W development process. SRS writer should be careful not to go beyond the bound of that role.
1. o o
The SRD should define all of the software requirements but no more. In particular, the SRD should not describe any design, verification or project management details. “The table is ordered for binary search.” “The table is organized for efficient search.” “The search must be completed in time O (log (log N ).” ).”
2.
Correct: An SRS is correct if and only if, every requirement stated there in is one that S/W shall meet. E.g. If the S/W stated that within 10 seconds, then the SRS is incorrect.
3.
The SRD must be . There should be exactly one interpretation of each sentence. Special words should be defined. Some SRDs use a special notation for words used in a specific way: !cursor!. Avoid “variety” — good — good English style, but not good SRD style. Careful usage. “The checksum is read from the last record.”
o
Does “last” mean (a) at end of file, (b) most recently read, or (c) previous? i nput file.” “. . . from the final record of the input “. . . from the record most recently processed.”
th
th
th
