1

Unit 1: • Software Engineering • Software • Software Program and Software Product • The software problems • Software Engineering • Problems of SE • SE Approach • Plan & Metrics Unit 2: • SDLC • Information System • Features of a good information system • Types of information systems Unit 3: • Various models of SDLC • Waterfall model • Prototyping • Incremental • Spiral model • Role of Management in Software Development • Role of Metrics and Measurement • Software Requirement Specification • SRS • Requirement Process • Problem Analysis • Analyst • Analysis Issues • Informal • Structured – DFD, Data Dictionary • Prototyping • Requirement specification • Validation

2

• Metrics • Size • Quality Unit 4: • Software Project Management • Cost Estimations • Project Scheduling and Milestones • Staffing and Personnel Planning • Software Configuration Management Plans • Quality Assurance Plans • Project Monitoring • Risk Management

3

Define Software Software is defined as the collection of computer programs, procedures, rules and associated documentation and data. Software could be a program or product. Software Program and Programming Software Product Features of a program • A program is complete in itself • Generally used only by the author of the program • Very little documentation or other aids to help other people use the program • Presence of “bug” is not a major issue as the author is the user • If the program crashes, the author will fix the program and start using it again • The program is not designed with these issues • Portability • Reliability • Usability

A software program • Is used by large number of people other than the developers • The users could be from different backgrounds, thus proper user interface is required • Sufficient documentation is required to help diverse users use the system • Programs are thoroughly tested before operational use, because the users do not have the luxury to fixing bugs that may be detected • The program is has to be designed with these issues • Portability : as it would be used in variety of environments • Reliability

4

• Usability

A lot more effort and resources are required for programming a system product. It is said that programming system products costs approximately 10 times as much as a corresponding program.

5

What are the problems of developing a software?

Software is expensive With the advancement of technology, the cost of hardware has consistently decreased. Foe example the cost of memory decreased more than 50 fold in two decreased. Similarly with the processors; virtually every year newer and faster processors are introduced that provide many times the computer power of earlier mainframe system at a cost that is a fraction of the mainframe systems. On the other hand, the cost of software is increasing. The main reason being that software development is still labourintensive. Let us consider the current state of practice in the industry. Delivered lines of code (DLOC) is the most commonly used measure of software size. The cost of developing software is generally measured in terms of person-month of effort spent in development Late, Costly and Unreliable Late: The software industry has gained a reputation of not being able to deliver on time and within budget. Costly: A large number of instances have been quoted regarding the unreliability of software; the software does not do what it is supposed to do or does something it is not supposed to do. Unreliable: Software failures are different from other failures like mechanical or electrical systems. Products of these other engineering disciplines fail because of the change in physical or electrical properties of the system caused, failures occur due to bugs or errors by ageing. While a software product never wears out because of age. In software failures occur because of bugs or errors that got introduced during the design and development process. Hence, even though a software may fail after operating correctly for some time, the bug that causes that failure was there from the start. It

6

only got executed at the time of the failure. This is quite different from other systems, where if a system fails, it generally means that sometime before the failure the system developed some problem that did not exist earlier.

The Problem of Change and Rework Once the software is delivered and deployed, it enters the maintenance phase. All systems need maintenance, but for other systems it is largely due to the problems that are introduced due to ageing. Software needs maintenance because of some residual errors remaining in the system. They need to be removed as they are discovered. Many of these errors may surface only after the system has been in operation, sometimes for a long time. These errors are removed leading to the software getting changed. This is called corrective maintenance. The software often needs to be upgraded and enhanced to include more features and provide more service. This requires modification to the software. This is called adaptive maintenance. Maintenance involves understanding the existing system, understanding the effects of change, make the change – to both the code and the documents – testing new parts and retesting the old parts. Often during development, the needs of maintenance are not kept in mind and few support documents are produced during development. The complexity of the maintenance task, coupled with the neglect of maintenance concerns during development, makes maintenance the most costly in the life of software product. Software Engineering
Software engineering is the systematic approach to the development, operation, maintenance and retirement of software. It is a technique by which we can develop software

7

that is economical, reliable and works efficiently on real machine. Problems of Software Engineering

The Problem of Scale
A fundamental problem of software engineering is the problem of scale. The development of a very large system requires a very different set of methods compared to developing a small system. That is, the methods that are used for developing small systems generally do not scale up to large systems. Example, counting people in a room verses taking a census of a country. Both are essentially counting problem; but the methods used for counting people in a room will not work when taking a census. For the census counting we would require more management, organisation and validation in addition to counting. Similarly, methods that one can use to develop programs of a few hundred lines can not be expected to work when software of a few hundred thousand lines needs to be developed. A different set of methods has to be used for developing large software. In small projects, informal methods for development and management can be used. However, for large projects, both have to be much more formal.

8

Formal Large Complex Projects

Project Management Y-Axis

Small Project

Informal Informal Development Metho ds Formal

9

A project is small if its size in thousands of delivered lines of code (KDLOC) is 2 KDLOC, medium if the size is 32 KDLOC and large if the size is 128 KDLOC or higher.

Cost, Schedule and Quality
Software engineering is driven by three major factors: cost, schedule and quality. In some contexts, cost and quality are considered the primary independent factors, as schedule can be modelled as cost or considered as an independent variable whose value is more or less fixed for a given cost. A practical and consistent goal on software engineering is to come up with methods of producing software more cheaply. Cost is a consistent driving force in software engineering. The cost of developing a system is the cost of resources used for the system, which in the case of software, are the manpower, hardware, software and the other support resources. Generally, manpower is predominant, as software development is largely labour-intensive and the cost of computing systems is now quite low. Hence, the cost of a software project is measured in terms of person-month i.e. the cost is considered to be the total number of person-months spent in the project. Schedule is an important factor in many projects. Business trends are dictating that the time to market a product should be reduced; that is, the cycle time from concept to delivery should be small. Any business with such a requirement will also require that the cycle time for building the software needed by the business be small. Where a reduced cycle time is highly desirable even if the costs become higher, there is a growing interest in Rapid Application Development (RAD).

10

One of the major factors driving any production discipline is quality. In the current times, quality is the “chief” requirement and all the business strategies are designed around quality. We can view quality of a software product as having three dimensions

S oftw are Q uality Factors

M aintainab ility F lexib ility T estab ility

Po rtab ility R eusab ility Intero p erab ility

Pro d uct R evisio n

P ro d uct T ransitio n

Pro d uct O p eratio n

Co rrectness R eliab ility Efficiency Integ rity U sab ility

 Product Operations – Correctness, reliability and efficiency  Product Transitions – Portability and interoperability  Product Revisions – Aspects related to modification of programs like maintainability and testability

Correctness is the extent to which a program satisfies its specifications Reliability is the property that defines how well the software meets its requirements.

11

Efficiency is a factor related to issues related execution of software, like response time, memory requirement and throughput. Usability deals with the human aspect of the system i.e. the effort required to learn and operate the software properly. Maintainability is the effort required to locate and fix errors. Testability is the effort required testing to ensure that the system or a module performs its intended function. Flexibility is the effort required to modify the program Portability is the effort required to transfer the software from one hardware configuration to another Reusability is the extent to which parts of the software can be reused in other related applications. Interoperability is the effort required to couple the system with other systems. The Problem of Consistency An organisation involved in software development does not just want low cost and high quality for a project, but wants it consistently. A software development organisation would like to produce consistent quality with consistent productivity. Consistency of performance is an important factor for any organisation. It allows an organisation to predict the outcome of a project with reasonable accuracy, and to improve its processes to produce higher-quality products and improve its productivity.
The Software Engineering Approach The basic objective of software engineering is to: Develop methods and procedures for software development that can scale up for large systems and that can be used to consistently produce high quality software at low cost, high quality and with small cycle time. That is, the key objectives are consistency, low cost, high quality, small cycle time and scalability  Phased Development Process

12

 Project Management and Metrics Phased Development Process 1. Analysis activities are those that provide a thorough understanding of the business information needs and requirements. The focus of analysis is on the business need & not on any particular computer technology. 2. Design activities are those that define the architecture and structure of a new system to satisfy those requirements. It’s during design that analyst starts conceptualising the system solution. 3. Implementation is actual construction, testing and installation of a functioning information system Project Management and Metrics A development process does not specify resources to different activities in the process. Nor does it specify things like schedule for the activities, how to divide work within a phase, how to ensure that each phase is being done properly, what are the risks for the project, how to solve the problems etc. Without proper handling, it is unlikely that the cost and quality objectives could be met. These types of issues fall in the domain of project management.

Plan: Management activities in a project revolve around a plan. A software plan forms the baseline that is used heavily for project monitoring and control during project execution.
All project management activities require information, upon which the management decisions are based. Otherwise, even the essential questions like the cost overrun, schedule etc, can not be answered. And for effective project management, objective i.e. concrete data is required. For this metrics are used.

13

Metrics Software metrics are quantifiable measures that could be used to measure different characteristics of a software system. There are two types of metrics:  Product Metrics: They are used to quantify characteristics of product being developed i.e. the software.  Process Metrics: They are used to quantify characteristics of the process being used to develop the software. They aim to measure such considerations as productivity, cost and resource requirements, effectiveness of quality measures etc.
Metrics and measurement are necessary aspects of managing a software development project. For effective monitoring, the management needs to get information about the project: how far it has progressed, how much development taken place, how far behind schedule it is, the quality of development etc. Based on this information, decisions can be made about the project. Without proper metrics to qualify the required data, subjective opinion would have to be used, which is often unreliable and goes against the goals of engineering.

14

SYSTEM DEVELOPMENT LIFE CYCLE A project is a planned undertaking that has a beginning & an end and produces a predetermined result or product. The term system development project describes a planned undertaking that produces a new system. The development of a new information system requires 3 major sets of activities – Analysis Design Implementation
1. Analysis activities are those that provide a thorough

understanding of the business information needs and requirements. The focus of analysis is on the business need & not on any particular computer technology. 2. Design activities are those that define the architecture and structure of a new system to satisfy those requirements. It’s during design that analyst starts conceptualising the system solution. 3. Implementation is actual construction, testing and installation of a functioning information system

Each set of activities is a phase. Thus there are 3 phases of development. And there is a post & a pre phase also.

Project Planning Phase

ANALYSIS

DESIGN

IMPLEMENTATION

Support Phase

15

4. Project Planning Phase consists of activities that are

required to initiate, plan and obtain approval for the project. It’s normally a short phase, but is critical to the overall success of the project 5. Support Phase includes the activities that maintain and enhance information system during its productive lifetime. It encompasses a much longer period of time than all the other phases combined. And usually the most expensive.

16

Phases of SDLC

Planning Phase (Feasibility phase) The steps during this phase 1. Define the problem – Define precisely the business problem and scope of required solution. Thus identify the major uses of the new system. 2. Confirm project feasibility – This includes financial, operational, technical and schedule feasibility 3. Produce project schedule 4. Staff the project - A detailed project schedule with tasks, activities and required staff is developed. 5. Launch the project - The total plan is reviewed with the upper management and the project is initiated. Initiation entails allocating funds, assigning project members and obtaining other necessary resources such as office and development tools.

17

Analysis Phase/ Requirement analysis
Thus is done in order to understand the problem the software system is to solve. The problem could be automating an existing manual process, developing a new automated system or combination of two. The focus is on “what” is needed from the system and not on how the system will achieve its goals. There are two major activities in this phase: problem understanding i.e. analysis and requirements document. Analysis requires thorough understanding of the existing system parts of which is to be automated, understanding the data entities, major centres where action is taken, purpose of different actions and inputs & outputs. This requires interaction with clients and users. The steps during this phase (i) Gather Information – System analysts meet with users to learn as much as possible about the problem domain. Analysts obtain information by observing the users performing business procedures, by interviewing and asking questions, by reading existing documents and reviewing existing system (ii) Define system requirement – The information obtained is reviewed, analysed and structured so that an overall understanding of requirements for the new system can be developed. (iii) Build prototypes for discovery of requirement – Build prototype of pieces of new system for the users to review. (iv) Prioritise requirements (v) Generate and evaluate alternatives - As requirements are prioritised, various alternative solutions are researched.

18

(vi)

Review recommendation – this is done with the management. One of the alternatives is selected and recommended to upper management.

The requirement phase ends with a document describing all the requirements. This is the software requirement specification document i.e. SRS or requirements document. The person responsible for the requirement analysis is called the analyst. The requirements document must specify all functional and performance requirements; formats of input and outputs and all design constraints that exist due to political, economical and security reasons.

19

Design Phase This phase is to design the system. Design moves from what is needed towards how to solve the needs. The output of design phase is the design document. It consists of system design and detailed design. System design or high level design consists of developing an architectural structure for software programs, databases, user interfaces and operating environment. Its aim is to identify the modules, and how they interact with each other to produce desired results. Detailed design or low-level design entails developing detailed algorithms and data structures that are required for program development. In system design the attention is on what components are needed, while in detailed design how the components can be in the software is the issue. Design phase utilises the information obtained from analysis phase as it’s input. It encompasses: (i) Design & integrate the Network – It consists of computer equipment, network and operating systems platforms that will house the new information system. (ii) Design application architecture – It consists of taking the model diagrams of the requirements that were developed during analysis phase and design appropriate computer program. (iii) Design User Interface – It involves design of forms, reports, screens and sequence of interactions. (iv) Design System Interface – This is to design as how the system will communicate with each other and with the existing system. (v) Design & Integrate Databases – This is to design the database that will support the new system. (vi) Prototype of Design Detail – It is required to verify the workability of the proposed design.

20

(vii) Design & Integrate System Controls – This is required to design the mechanisms to protect information and assets of the organisation.

21

Implementation Phase During this phase the final system is built, tested and installed. It encompasses (i) Construct Software Components or Coding – Its goal is to translate the design of the system into code in a given programming language. Various techniques are used for construction. E.g. VB, Java (ii) Verify & Test – Its required to test that system actually works. Additional testing is required to make sure that the new system meets the need of users. (iii) Develop Prototype for Tuning – This is to verify that the system is tuned to handle large volume of data in production. (iv) Convert Data – Gather data from the existing system and convert it to the format required in the new system. (v) Train and Document – Train the users on the new system so that they will be productive. (vi) Install the system – To verify that the new equipment are in place and functioning, check that new computers are installed and working, database is populated and made available.
Well-written code can reduce the testing and maintenance effort. Because testing and maintenance costs of software are much higher than the coding cost, the goal of coding is to reduce testing and maintenance effort.

Testing is the major quality control measure used during software development. Its basic function is to detect errors in the software. Its goal is to uncover requirement, design and coding errors in the programs. During unit testing, a module is tested separately and is often performed by the coder himself; simultaneously along with the coding of the module. After this, the modules are generally integrated into

22

subsystems, which are then integrated to eventually form the entire system. During integration testing the focus is to detect design errors by focusing on testing the interconnection between modules. After the system is put together, a system test is performed. Here the system is tested against the system requirements to see if all the requirements are met and if the system performs as specified by the requirements. Finally acceptance testing is performed to demonstrate to the client, on real life data of the client, the operation of the system. Testing is extremely critical and time-consuming activity. It requires proper planning of the overall testing process. He testing process starts with a test plan that identifies all testing related activities that must be performed and specifies the schedule, allocates resources and testing guidelines. A test case specification document is produced, which lists all the different test cases together with expected results. During testing the actual result is compared to the expected result. The final output of testing phase is the test report and the error report. Test report contains the set of test cases and result of executing the code. The error report describes the errors encountered and action take to remove the errors.

23

Support Phase This phase encompasses (i) Providing Support to the End Users – It is achieved through ongoing training programs and help desks. (ii) Maintaining & Enhancing the Current System – This involves correcting simple program error to comprehensive enhancements and upgrades.
There are 4 types of changes a) Correction - Correcting program defects b) Adaptation – When original environment for which the system was developed is changed c) Enhancements – The software used has additional features that would be beneficial. d) Prevention – Computer software deteriorates due to change and because of this preventive maintenance must be conducted.

24

Information System Data is raw fact about the organisation; it’s business, transactions etc. They have little meaning and use by themselves and need to be organised. Information is data that has been refined and organised by processing and purposeful intelligence. Information System is a collection of interrelated components that collect, process, store and provide as output the information needed to complete a business task. It can also be defined as an arrangement of people, data, processes, interfaces and geography that are integrated for the purpose of supporting and improving the day to day operations in a business as well as fulfilling the problem solving and decision making information needs of the business. Featured of a good information system 1. Useful and usable The system should be useful to the user i.e. it should perform the required tasks. And should be usable i.e. user should be able to operate the system easily. 2. Reliable The system should maintain the integrity of the information stored and should be reliable i.e. consistent with its performance. 3. Flexible and easy maintenance It should be easily modified or updated i.e. new functions can be incorporated or existing system can be tuned with ease. 4. Affordable The system should be worth its cost.

25

Different Types of Information Systems 1. Systems Software 2. Real Time Software 3. Artificial intelligence 4. Embedded 5. Web based 6. Engineering and scientific 7. Business software 1. System Software It’s a collection of programs written to service other programs. E.g. compilers, editors, operating system 2. Real Time Software They monitor, analyse or control real time world events. They require to react immediately to events in the environment. Elements of real time software are Data gathering components Analysis components Control output components Monitoring components E.g. In air plane guidance system, if the air plane’s altitude drops below 5000 feet then the system needs to turn on low altitude alarm. 3. Artificial intelligence Software They make use of non-commercial algorithms to solve complex problems. Also know as knowledge based system. E.g. thumb impression system, computer games 4. Embedded System They are intelligent products that reside in read only memory and used to control products and systems for the consumer & industrial market

26

E.g. Hyundai car, telecom switches 5. Web Based System Web pages retrieved by browser E.g. pearl, Java 6. Engineering & Scientific System E.g. stress analysis, space orbital dynamics, molecular biology 7. Business Software Transaction Processing System (TPS or Data Processing System) Transaction Processing system captures and records information about the transactions that effect the business. Business transactions are defined as events that serve the mission of business. Processing systems are information system that capture and process data about business transaction. TPS can either respond to a business transaction (e.g. order, payment) or initiate a transaction (e.g. invoice generation, paycheque, receipts) or both. Also TPS can respond to both external events (e.g. processing order from customer) or internal events (e.g. generating production orders from shop floor) E.g. Payroll, inventory, financial accounting

Management Information System (MIS) Its an information system that takes information captured by transaction processing system and produces reports that management needs for planning and control. It represents (i) Detailed information used for operations management as well as regulatory requirement

27

(ii)

Summary information which consolidates raw data quickly to indicate trends and possible problems. (iii) Exception information which filters data to report exceptions to some rule or criteria This information is generated on a predetermined schedule and appears in prearranged formats.

Decision Support System It supports decision-maker by providing information on demand. They are designed to support unstructured decisions. E.g. how many rental cars to move from one city to another for a holiday weekend based on estimated business travel patterns. Executive Information System It provides information to executives to use in strategic planning. Some information comes from organisational database and some from external sources (e.g. stock market, economic forecast) Communication Support System It allows employees to communicate with each other and with customers & suppliers. E.g. email, fax, internet access, video conferencing Personal Information System It builds applications for individuals. It is designed to meet the needs of a single user, generally to boost an individual's productivity. Office Information System It helps employees create and share documents including reports, proposals and memos. They also help maintain information about work schedules and meetings. They

28

provide for communications between workers regardless of whether or not workers are physically located in same office. E.g. Lotus Notes

Expert System It is an extension of Decision Support System. It is a programmed decision making information system that captures and reproduces the knowledge and expertise of an expert problem solver or decision maker and then simulates the “thinking” or “actions” of that expert. E.g. X-ray diagnosis. This expert system incorporates the inference engine to examine the shadows on the X-ray. The shadows are used to determine the type and the degree of damage.

29

Software Development Life Cycle Models
(A) Waterfall Model (Linear Sequential Model)

It is a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing and support. Here each life cycle phase is completed in sequence and then the result of the phase flow into the next phase. It insists on careful planning and control of the project. The decisions made at each phase are frozen, meaning they can not be changed. It consists of the following activities:

Analysis

Design

Code

Test

1. Software requirement analysis and planning 2. System design & detailed designed– It focuses on 4 distinct attributes of the program Data structure Software architecture Interface representation Procedural detail The design process translates requirements into a representation of the software that can be assessed for quality before coding begins 3. Code Generation – The code generation step translates the design into machine-readable form. If design is performed

30

in detailed manner, code generation can be accomplished mechanically. 4. System integration and testing – This process focuses on logical internals of the system. a) Ensures that all statements have been tested b) Uncovers errors c) Ensure that defined input will produce actual required results There are two basic assumptions for justifying the linear ordering of phases in the manner proposed by the waterfall model: 1. For successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway 2. Any different ordering of the phases will result in a less successful software product. The following set of documents are produced in each project • Requirements document • Project plan • System design document • Detailed design document • Test plan and test reports • Final code • Software manuals • Review reports

Drawbacks of the system Real world projects rarely follow sequential flow that the model proposes. This is so because 1. This model assumes that the requirements of a system can be frozen before the design begins. This is possible when

31

2. 3.

4.

5.

the system is to automate an existing manual system. But for new systems, determining the requirement is difficult as the user does not know the requirements. It is often difficult to freeze the demand of the customer Freezing requirements usually requires choosing the hardware. A large project might take few years to complete. Due to the speed at which hardware technology is changing, it is likely that the final software will use an obsolete hardware technology The customer needs to have patience. A working version of the program will not be available until late in the project time span. A major blunder if undetected until the working programs are reviewed can be disastrous. It leads to blocking states i.e. some project team members of the team must wait for other members of the team to complete dependent tasks.

(B)The Prototype Paradigm Often during a project a set of general objectives for the software is defined but has not identified detailed input, processing or output requirement. In some cases the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system etc. In such cases a prototype paradigm is approached. It begins with requirement gathering. Developers and customers meet and define overall objectives of the software, identify whatever requirements are known and outline areas where further definition is mandatory. A “quick design” then follows. The quick design focuses on a representation of those aspects of the software that will be visible to the user. This leads to construction of a prototype. This prototype is evaluated and used to refine requirements. Iteration occurs as the prototype is tuned to satisfy the needs of the customer. By using this prototype, the client

32

can get an actual feel of the system. This results in more stable requirements that change less frequently.

Listen to custom er

Build / Revise m ock-up

Custom er test drives m ock-up

Thus prototype serves as a mechanism for identifying software requirements. In some cases it might reduce the cost of software development. As: 1. The experience of developing the prototype might reduce the cost of later phase when the actual software development is done 2. In many projects the requirements are constantly changing. Drawbacks 1. The prototype is a working version of the software. The customer is unaware that the prototype is loosely held and in the rush to get it working no one has considered the overall quality and long term maintainability. 2. The developer often makes implementation compromises to get the prototype working quickly. 3. It can be a life long loop. And thus might increase the project cost

33

(C)The Incremental Model It combines the elements of linear sequential model with the philosophy of prototyping. Each linear sequence produces a deliverable “increment” of the software i.e. the software is developed in increments, each increment adding some functional capability to the system until full system is implemented. E.g. a word processor software. The main task is to create a project control list that contains all the tasks that must be performed to obtain the final implementation. Each step consists of removing the next task from the list and performing the analysis, design & implementation to it. The first increment is the core product. That is the basic requirements are addressed, but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customers. As a result of the use and evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of customer & delivery of additional features & functionality. This process is repeated following the delivery of each increment, until the complete product is produced.

34

System / Information Engineering Analysis Design

Increm ent 1 D elivery of 1 st Increm ent

C ode

T est

Increm ent 2

Analysis

D esign

C ode

T est

D elivery of 2 nd Increm ent

Increm ent 3

Analysis

D esign

C ode

T est

D elivery of 3 rd Increm ent

Increm ent 4

Analysis

Design

C ode

T est

D elivery of 4 th Increm ent

Tim e

This model is iterative as prototype model but unlike prototype model it delivers operational product with each iteration. Every increment is stripped down version of the final product, but they do provide capability that serves the users and also a platform to evaluate. Advantages (i) Better testing as testing each increment is likely to be easier than testing the entire system as in the waterfall model (ii) It provides feedback to the client that is useful for determining the final requirements of the system. (iii) Most useful when staffing is unavailable for a complete implementation. Early increments can be developed by fewer people. If the core product is well received, then additional resources are added. (iv) Increments can be planned to manage technical risks. E.g. a major system might require the availability of a new hardware that is under development. It might be

35

possible to plan early increments so as to avoid use of this hardware. Disadvantages (i) As it is an iterative process, many times, time commitments are not fulfilled. (ii) It can not be predicted within how many iterations the project will be completed to desired level. (iii) In a customised development, where the client has to essentially provide and approve specifications, it is not always clear how this process can be applied.

(D)Spiral Model Fig2.9 The activities in this model can be organised like a spiral that has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing the steps done so far, and the angular dimension represents progress made in completing each cycle of the spiral. Each cycle of the spiral begins with the identification of the objectives for that cycle, the different alternatives that are possible for achieving the objectives and the constraints that exist. This is the first quadrant of the cycle (upper left quadrant). The next step in the cycle is to evaluate these different alternatives based on the objectives and constraints. The focus of evaluation in this step is based on the risk perception for the project. The next step is to develop the strategies that resolve the uncertainties and risks. This step may involve activities like benchmarking, simulation and prototyping. Next, the software is developed, keeping in mind the risks. Finally the next stage is planned.

36

An important feature of the model is that each cycle of the spiral is completed by a review that covers all the products developed during the cycle, including plans for next cycle. This model works for development as well as enhancement projects. Disadvantages (i) Demands risk assessment expertise (ii) It is a difficult model to convince customers.

37

Role of Management in Software Development A development process typically partitions the problems of developing software into a set of phases. To meet the cost, quality and schedule objectives, resources have to be properly allocated to each activity for the project, and progress to different activities has to be monitored and corrective actions taken, if needed. All these are part of project management process. The project management process component of the software process specifies all activities that need to be done by the project management to ensure that cost and quality objectives are met. The basic task of project management is to ensure that, once a development process is chose, it is implemented optimally. The focus of the management process is on issues like planning a project, estimating resource and schedule, and monitoring & controlling the project. Thus, the basic task is to plan the detailed implementation of the process for the particular project and then ensure that the plan is followed.

Phases of Management Process The activities in the management process for a project can be grouped broadly into three phases 1. Planning 2. Monitoring & control 3. Termination analysis
The project management begins with planning. The goal of this phase is to develop a plan for the software following which the objectives of the project can be met successfully and efficiently. Proper planning is the critical ingredient for a successful project. A software plan is usually produced before the development proceeds and data about the progress of the project becomes available. During planning, the major activities are

38

• • • • •

cost estimation schedule and milestone determination project staffing quality control plans controlling & monitoring plans.

In cost and schedule estimation, the total cost and time needed for successfully completing the project are estimated. In addition, cost and schedule for the different activities of the development process to be used are also estimated. The project plan plans for all the software quality assurance activities that need to be performed in order to ensure that quality objectives are met. A plan also provides methods for handling change and methods for monitoring a project. Project monitoring and control phase of the management process encompasses most of the development process. It includes 1. all activities that the project management has to perform while the development is going on to ensure that the project activities are met and that the development proceeds according to project plan. And thus update the plan if needed. 2. A lot of the activities of the phase revolve around monitoring the factors effecting the cost, schedule and activity. 3. Monitoring potential risks for the project, which might prevent the project from meeting its objectives. 4. If the information obtained by monitoring suggests that objectives may not be met, necessary actions are taken by exerting suitable control on the development activities. The development process provides information the management process needs for monitoring and control.

39

Termination analysis is performed when the development process is over. The basic reason for performing termination analysis is • To provide information about the development processes A project is an instantiation of the process. To understand the properties of the process, data from many projects that used the process will be needed. This data can be used to make predictions and estimations about the future projects. • The data about the project us also needed to analyse the process.

40

Role of Metrics and Measurement PRESENTATION in class

41

Software Requirement The fundamental problem with software engineering is the problem of scale. The complexity and size of applications are continuously increasing. For large software systems, requirement analysis is the most difficult and is also very error-prone. Some of the difficulty is due to scope of this phase. The software project is initiated by the client’s needs. Generally, in the beginning, these needs are in the minds of various people in the client organisation. The requirement analyst has to identify the requirements by talking to these people and understanding their needs. In situation where the software is to automate a currently manual process, many of the needs can be understood by observing the current process. But no such methods exist for systems for which manual processes do not exist. In such case things gets more complicated as the needs & requirements of the system are not very clear to the clients. The requirement phase translates the ideas in the minds of clients into a formal document. And thus is SRS is created SRS is a document that completely describes what the proposed software should do without describing how the software will do it. The basic goal of requirements phase is to produce the SRS, which describes the complete external behaviour of the proposed software.

Needs of SRS • An SRS establishes the basis for agreement between the client and supplier on what the software product will do. At times there could be communication gap between the client team and the development team. Thus a SRS is produced to bridge this communication gap. SRS is the medium through which the client needs are accurately specified. Thus it helps the clients to understand their own

42

needs. At times, the client has to be made aware of better potentials. • An SRS provides a reference for validation of the final product. Through SRS the client clearly describes what it expects from the supplier and the developer clearly understands what capabilities to build in the software. • A high quality SRS is a prerequisite to high-quality software. An error in SRS is most likely to manifest itself as an error in the final system implementing the SRS. That is, if the SRS document specifies a wrong system, then even a correct implementation of the SRS will lead to a system that will not satisfy the client. • A high-quality SRS reduces the development cost. The cost of fixing an error increases almost exponentially as the time progresses. That is, a requirement error if detected and removed after the system has been developed can cost up to 100 times more than removing it during the requirements phase itself.

The Requirement Process The requirement process is the sequence of activities that need to be performed in the requirements phase and that produces a high quality document i.e. the SRS. It consists of three basic activities  Problem or requirement analysis  Requirement specification  Requirements validation

43

The first aspect deals with understanding the problem, the goals, the constraints etc. Here the focus is on understanding the system and its requirements. In specification, we have to specify only what the software is supposed to do i.e. focus on the external behaviour of the system. Above three are discussed in details in the following sections
Client/User Needs

Problem Analysis

Product Description

Validation

Validated SRS

44

Problem Analysis The main aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, what exactly is desired from the software and what the constraints on the solution are.

Who is an analyst? Analyst is a person performing the task of analysis. Tasks of an analyst include • Research a problem by asking questions of the clients and users • Research a problem by reading existing documents • Help clients and users identify their needs.
Thus it is important that the analyst thoroughly understand 1. The client’s organisation and its purpose 2. The problem domain 3. The purpose of automation.

Analysis Issues There are several analysis issues 1. To obtain necessary information. This can be achieved through • Interacting with users using questionnaire and interviews • Reading existing documents 2. To organise the information obtained so that the information could be effectively evaluated 3. Resolve the contradictions that may exist in the information from different parties. 4. To avoid internal design
The basic principal is to partition the problem into subproblems. And then try to understand each subproblem and its relationship to other subproblems.

45

The principles used during analysis to partition the problem into subproblems • Objects: An object is an entity that has clearly defined boundaries and an independent existence • Functions: A function is a task, service, process, mathematical function or activity • State: It represents some conditions about the system • Projection: Here a system is defined from multiple points of view. There are three basic approaches to problem analysis 1. Informal method: based on structured communication and interactions 2. Conceptual modelling: it is formal method that uses the principle of partitioning. 3. Prototyping: the problem is analysed and requirements understood through the feedback from the users and clients.

Informal Approach The informal approach to analysis is one where no defined methodology is used. The information about the system is obtained by interaction with the client, end users, questionnaires, study of existing documents, brainstorming etc. In this approach no formal model is built and the problem definition is directly translated from the mind of the analyst to the SRS. The analyst will have a series of meeting with the clients and end users. The client and end users will explain to the analyst about their work, their environment and their need, as they perceive them. Once the analyst understands the system to some extent, he uses the next few meetings to seek clarification on the part he does not understand. In the final

46

few meetings, the analyst explains to the client what he understands the system should do.

Structured Analysis It focuses on the functions performed in the problem domain and the data consumed and produced by these functions. It helps analyst decide what type of information to obtain at different points in analysis and it helps organise information. Several techniques used by this approach: 1. Data Flow Diagrams 2. Data Dictionary Using these techniques the structured analysis method is done Data Flow Diagram A DFD shows the flow of data through a system. It views the system as a function that transforms the inputs into desired outputs. A data will typically undergo a series of transformations before it becomes the output. It aims to capture the transformations that take place within a system to the input data so that eventually the output data is produced. The agent that performs the transformation of data from one state to another is called a process. Several notations used are:
• Processes are shown by named circles • Data flows are represented by named arrows entering or leaving the bubbles • Rectangle represents a source or sink and is a net originator or consumer of data. • * is used to represent multiple data flows DFD is an abstract description of the system. It does not matter if the system is automated or manual. Some suggestions for constructing a DFD:

47

• Work consistently from input to output or vice versa. Start with high level DFD with few major transforms and then refine each transform with detailed transformations • Never show control logic • Label each arrow with proper data elements. • Try drawing alternate graphs before settling on one.

Data Dictionary The data dictionary is a repository of various data flows defined in DFD Example, Employee_Name = Last + First + Middle_Initial Weelkly_Timesheet = Employee_Name + Employee_Id + [Regular_Hours + Overtime_Hours] *
Some common errors during DFD: • Unlabeled data flows • Missing data flows • Missing information • Consistency not maintained during refinement • Missing processes • Contains control information

The Method The basic idea is that each system can be viewed as a transformation function operating within an environment that takes some input from the environment and produces some outputs for the environment. The system is partitioned into subfunctions, which can further be partitioned Steps during this process 1. Study the physical environment 2. Make a logical DFD of the system

48

3. Make a logical model of the new system. Here the analyst specifies only what needs to be done, not how it will be accomplished 4. Specify the “automation boundary”. Thus, specify what will be automated and what will remain manual. 5. Evaluate different options 6. Packaging or presenting the specifications.

Prototyping In prototyping, a partial system is constructed which is then used by the client, users and developers to gain a better understanding of the problems and needs. There are two approaches for prototyping: • In throwaway approach the prototype is constructed with the idea that it will be discarded after the analysis is done and the final system will be built from scratch • In evolutionary approach, the prototype is built with the idea that it will eventually be converted into the final system

49

Requirement Specification Mostly, the problem analysis and specification are done concurrently. An analyst typically will analyse some parts of the problem and then write the requirements for that part. Thus in practice, problem analysis and requirement specification activities overlap. The following are NOT in focus during the problem analysis while they are important part of the SRS document: • User Interface • Erroneous situation • Performance constraints • Design constraints • Standards used • Recovery The knowledge acquired from the problem analysis phase is passed on to the specification passed. And SRS is written based on this.

Characteristics of SRS A good SRS is 1. Correct: If every requirement included in the SRS represents something required in the final system 2. Complete: If everything the software is supposed to do and the response to all input data are specified Correctness involves examining each requirement to make sure it represents user requirement. While for completeness, one has to detect the absence of specification 3. Unambiguous: If and only if every requirement stated has one and only one interpretation 4. Verifiable: Verify that requirements meet specification 5. Consistent: There is no requirement that conflicts with another

50

6. Ranked for importance and stability: For each requirement rank its importance. Stability reflects the chances of it changing in the future. 7. Modifiable: The structure and style should be such that any necessary change can be made easily 8. Traceable: If the origin of each requirement is clear

Components of SRS The basic issues an SRS must address: 1. Functionality 2. Performance 3. Design constraints 4. External interfaces Functional Requirements Functional requirements specify which outputs should be produced from the given outputs. This includes • Validity checks on input & output. • Determining parameters effected by the system • Logical operations • Behaviour of system for invalid input and output. Performance requirements There are two types of performance requirements • Static: They do not impose constraints. Like the number of terminals, number of simultaneous users to be supported etc • Dynamic: They specify constraints on the execution behaviour of the system. It includes run time,, response time, throughput Design Constraints Identify and specify the following constraint: Standards Compliance: The standards the system must follow Hardware limitations Reliability and Fault tolerance

51

Security

External Interface design All possible interaction of the software with people, hardware and other systems

52

Structure of Requirements Document All the requirements for the system are included in the document and it should be clear and concise. The general structure of SRS • Introduction • Purpose • Scope • Definitions, Acronyms, Abbreviation • References • Overviews • Overall description • Product Perspective: Relationship of the product to other products. • Product functions • User characteristics • General constraints • Assumption and Dependencies • Specific requirements
Section 2 describes the general factors that affect the product. Section 3 describes all the details that the software developer needs for designing and developing the system:

• Specific requirements • External Interface Requirements • User interface • Hardware interface • Software interface • Communication Interfaces • Functional requirements • Mode 1 • Mode m • Performance requirements

53

• Design constraints • Attributes • Other requirement

54

• Validation PRESENTATION

55

Metrics The basic purpose of metrics during development project is to provide quantitative information to the management process so that the information can be used to effectively control the development process. This can be achieved by using some model to monitor and control the cost, schedule or quality of the project. There are two types of metric measurements defined for requirements: • Size for determining cost & schedule • Quality

Size A big problem after requirements are done is to estimate the effort and schedule for the project. For this a metrics “size” could be used to determine the cost and schedule of the development process. And for this following measurements could be used 1. Text-based Measures Determine the size of the text of the SRS. The size could be in number of pages, number of requirements etc. But this is highly dependent on the author of the document. Generally such metrics can not be accurate indicators. They are used mostly to convey a general sense about the size of the project. 2. Functional Point Functional Points or FP are one of the most widely used measures of software size. The basis of function point is that the “functionality” of a system, that is, what the system performs, is the measure of the system size. In function points, the system functionality is calculated in terms of the parameters, which can be obtained after requirement analysis. And the parameters are classified as

56

simple, average or complex. The five different parameters generally used are • External input types: Each unique data that is given as input to the application from outside. It is considered simple if it has a few data elements and affects only a few internal files of the application. It is complex if has many data elements and affects several internal files. And is considered average if it is in between. • External output types: Each unique output that leaves the system boundary is counted as external output type. Example, reports, messages. For a report, if it contains few columns it is considered simple. If multiple then average and if it contains complex structure of data and references to many files it is called complex • Logical internal file types: Each logical group of data or control information that is generated. Used and maintained by the application is called logical internal file type. It is considered simple if it contains few records, complex if many and average if it is in between. • External interface file types: Files that are passed and shared between applications. Complexity is same as before. • External inquiry types: Each unique input-output is said to be a query. For classifying the query type, each input & output is considered as external input and external output. A major drawback of the FP approach is that process of computing FPs involves subjective evaluation at various points. And thus may depend on the analyst.

57

3. Bang Metric The metrics assumes that a DFD diagram and data dictionary is used in the analysis process. It counts those bubbles, which can not be refined further

Quality Metrics
The SRS is assessed directly by evaluating the quality of the document. The measures used for this are: 1. Number of Errors Found The number of errors found can be obtained from the requirement review report 2. Change Request Frequency Requirements rarely stay unchanged. A change may come from the client or developer.

58

UNIT 4 Software Project Management Software development is highly labour-intensive activity. The large workforce has to be properly organised so that the entire workforce is contributing effectively and efficiently to the project. Proper management controls and checkpoints are required for effective project monitoring. For a successful project, competent management and technical staff are both essential. Project management activities have 3 major phases: • Project Planning • Monitoring and control • Termination analysis Planning is said to be the most important management activity. Without a proper plan no real monitoring or controlling of the project is possible. The input to the planning activity is the requirement specifications. And the output of this phase is project plan which is a document describing the different aspects of the plan. The major issues the project plan must address are • Cost estimation • Schedule and milestone • Personnel plan • Software quality assurance plan. • Configuration management plans • Project monitoring plans • Risk management

59

Cost Estimation For a given set of requirements it is desirable to know how much it will cost to develop the software to satisfy the give requirements and how much time development will take. These estimates are needed before development is initiated. The primary reason for cost and schedule estimation is to enable the client or developer to perform a cost-benefit analysis and for project monitoring/control. While the practical use is in bidding for software projects, where the developer must give cost estimates to a potential client for the development contract. Need of cost estimation • For the development process • For staffing the project during different phases Cost in a project is due to the requirements for • Software like tools and compilers needed during development. • Hardware like computer time, terminal time • Human resources The bulk of the cost of software development is due to human resources needed. Estimates can be based on subjective opinion of some person or is determined through use of models

60

Uncertainties in Cost Estimation: Cost of the project depends on • nature of the project • characteristics of the project When the project is being initiated we have only some idea of the classes of data the system will get and produce and the major functionality of the system. There is still a great deal of uncertainty about the actual specifications of the system. As we specify the system more fully and accurately, the uncertainties are reduced and more accurate cost estimates can be made.
Despite the limitations, cost estimation models have matured considerably and generally given fairly accurate estimates

Building cost Estimation Models The factors that controls the cost of a project are • Size of the project • Programmer ability • Experience of developers. • Complexity of the project • Reliability requirements. The goal of a cost model is to determine which of the many parameters have a significant effect on cost and then to discover the relationships between the cost and these characteristics. Example, of an equation often used in cost estimation Effort = a * SIZEb Where a and b are constants determined through analysis which is applied to data about the projects that has been performed in the past. SIZE is generally in terms of KDLOC.
But this model requires the size as input but size is not known early in development and has to be estimated. And if the size

61

estimate is inaccurate, the cost estimate produced by the models will also be inaccurate. In general, there is often a tendency by people to underestimate the size of the software. Reasons being • People are optimistic • Desire to please others • Avoid confrontation • Estimate on basis of previous experience while not remembering their experience completely

62

Project Scheduling and Milestones What is project scheduling? Limitations

Tools: PERT Chart (Project Evaluation and Review Technique) It is a graphical network model that depicts a project’s task and relationship between those tasks. PERT was developed to make clear the interdependence between project tasks before those tasks are scheduled. The boxes represent project tasks. The arrows indicate that one task is independent on the start or completion of another task. By defining which tasks can be done concurrently and which ones must be done serially, project managers can determine the total expected schedule of the project. The longest path, from the first task to the last task, of dependent tasks is called a critical path, because if any task in that path slips, then the entire project schedule will slip. Tasks not on the critical path have some slack time. The slack time for a task is the amount of time that the task can slip without affecting the schedule. A PERT chart also assists in assigning staff. It enables to balance the availability and the workload of the team members with dependent and independent tasks.

63

Project Initiation 5/3/2001 5/3/2001 n/a n/a

LEG END Task Scheduled Start Actual Start Scheduled Finish Actual Finish Intertask Dependency Scheduled Start Actual Start Task Scheduled Finish Actual Finish

Prelim inary Inv estigation 5/3/2001 5/3/2001 5/12/2001 5/11/2001

Problem Analysis 5/12/2001 5/12/2001 6/12/2001 6/14/2001

Requriem ent Analysis 5/28/2001 5/30/2001 7/15/2001 7/18/2001

Decision Analysis 6/13/2001 6/13/2001 7/30/2001 8/3/2001

Design 7/3/2001 7/5/2001 9/25/2001 10/9/2001

Construction 7/9/2001 7/20/2001 11/13/2001 In Progress

Im plelem entation 9/10/2001 TBD 12/14/2001 TBD

Gantt Chart It is a horizontal bar chart that depicts project tasks against a calendar. Each bar represents a named project task. The tasks are listed vertically in the left-hand column. The horizontal axis is calendar timeline.
Gantt chart offers the advantage of clearly showing overlapping tasks, i.e., the tasks that can be performed at the same time. The bars can be shaded to clearly indicate percentage completion and project progress. The figure demonstrates which phases are ahead and behind schedule at a glance. They are easy to learn, read, prepare and use.

64

PERT charts are useful in building initial project schedule while Gantt chart is more useful in tracking the project after it has begun. Gantt chart is more effective when one is seeking to communicate schedule. PERT chart is more effective when one wants to study the relationship between tasks.

65

Staffing and Personnel Planning

Staffing Once the project schedule is determined and the effort and schedule of different phases & tasks are known, staff requirements can be obtained. From the cost and overall duration of the project, the average staff size for the project can be determined by dividing the total effort (in person months) by the overall project duration. But this average staff size in not detailed enough for proper personnel planning, especially if the variation between the actual staff requirement at different phases is large. Typically the staff requirement for a project is small during requirement and design, the maximum during implementation and testing, and drops again during the final phases of integration. For personnel planning and scheduling, it is useful to have effort and schedule estimates for the subsystems and basic modules of the system. Personnel Plan Once the schedule and average staff level for each activity is known, the overall personnel allocation for the project can be planned. The plan will specify how many people will be needed for the different activities at different times for the duration of the project. Example of a software tool is MS Project Plan. It is a calendar based representation, containing all the months in the duration of the project, by listing the months from starting date to the ending date. Then, for each task identified list the number of people needed in each month. The total effort for each month and the total effort for each activity can easily be computed from this plan. A more detailed plan will list the requirements of the people by their speciality; for example, stating how many programmers, analysts, quality assurance people and so forth are needed at different times.

66

Drawing a personnel plan usually requires few iterations

Team Structure Often a team of people is assigned to a project. For the team to work as a cohesive group and contribute the most to the project, the people in the team have to be organised. There are 3 types of team structures • Democratic team • Chief programmer team • Controlled decentralised team

1. Democratic or Egoless Team This team consists of ten or fewer programmers. The goals of the group are set by consensus, and the input from every member is taken for major decisions. Group leadership rotates among the group members. 2. Chief Programmer Team This has a hierarchy team structure. It consists of a chief programmer, who has a backup programmer, a programmer librarian and other programmers. The chief programmer is responsible for all the major technical decision of the project. He does most of the design and he assigns coding of the different parts to the programmers. The backup manager helps the chief programmer make technical decisions. And takes over as the chief programmer when the chief programmer is on leave. The program librarian is responsible for maintaining the documentation and other communication related work. This structure considerably reduces interpersonal communications 3. Controlled Decentralised Team This structure combines the strengths of the democratic and chief programmer teams. It consists of a project leader who has a group of senior programmers under him, while

67

under each senior programmer is a group of junior programmers. The group of senior programmer and his junior programmers behaves like a egoless team, but communication between different groups occurs only through the senior programmers of the groups. The senior programmers also communicate with the project leader.

68

Software Configuration Management Plans

What is SCM? Throughout development, software consists of a collection of items that can easily be changed. During software development, the design, code and requirements are often changed, and the changes occur at any time during the development. This easily changeable nature of the software and the fact that changes often take place require that changes be done in a controlled manner. SCM is the discipline for systematically controlling the changes that take place during development. It is formally defined as: SCM is the process of identifying and defining the items in the system, controlling the changes to these items throughout their life cycle, recording and reporting the status of items and change requests and verifying the completeness and correctness of items. Though the changes during a SDLC is handled by the developers but approving the change, evaluating the impact of the change, decide what needs to be done to accommodate a change request etc. are issues that are handled by SCM. This allows changes in a controlled manner. The basic reason for having a SCM is that it has beneficial effect on cost, schedule and quality of the product being developed. The three major components of SCM are • Software configuration identification: Identify the SCI (Software Configuration Items). An SCI is a document or an artefact that is explicitly placed under configuration control and can be regarded as a basic unit for modification. • Change control: Decide on the change control procedures • Status accounting and auditing SCM Plan

69

The SCM plan identifies all the activities that must be performed, give guidelines for performing the activities and allocate resources for them. It specifies the SCIs, members of configuration control board, forms to be used for change requests, fault reporting, policies, procedures and tools for controlling the changes.

70

Quality Assurance Plans To ensure that the final product is of high quality, some quality control activities must be performed through out the development. If this is not done, correcting errors in the final stages can be very expensive. The purpose of software quality assurance plan (SQAP) is to specify • all the work products that need to be produced during the project • activities that need to be performed for checking the quality of each of the work product • tools & methods that may be used for the SQA activities. SQAP is interested in the quality of not only the final product, but also the intermediate product. This is due to the fact that in a project it is very unlikely that the intermediate work products are of poor quality and the final product is of high quality. Thus an SQAP will contain QA activities through out the project. Software quality is achieved through: • verification • validation • inspection • review

Verification and Validation (V & V) Verification is the process of determining whether or not the products of a given phase of software development fulfil the specifications established during the previous phase. Verification activities include • Proving • Testing • Reviews

71

Validation is the process of evaluating the software at the end of the software development to ensure compliance with the software requirements. Testing is a common method of validation. The two major V & V approaches are testing and inspection. Testing is an activity that can be generally performed only on code. While inspection is a more general activity that can be applied to any work product.

Inspection and Reviews Inspection is defined as “a formal evaluation technique in which software requirements, design or code are examined in detail by a person or a group other than the author to detect faults, violation of development standards and other problems.”

72

During inspection the peers perform a careful scrutiny of the product. The inspection of work product is done by a group of peers, who first inspect the product privately and then get together in a formal meeting to discuss potential defects found by individuals and to detect more defects. An inspection can be held for any technical product, which may include SRS, system design document, detailed design, code and test plan. There are three reasons: • Defect Removal: This specifies the need to detect defects as early as possible. • Productivity increase: As errors are being detected and removed, productivity improves. Cost decreases as defects are being detected. • Improve quality control benefits. It helps improve software quality by checking properties like standard compliance, clarity, simplicity, modularity • As coders and designers learn from defects found in reviews of their work, it enables them to avoid causing similar defects in future, thus improving quality and productivity • Provide information for project monitoring Review is the process to provide enough information to the management about the project so that management decisions can be made effectively

73

Project Monitoring Plan PRESENTATION

74

RISK MANAGEMENT PRESENTATION

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.