Software Project Management

Q1. (a) What are the characteristics of a good software?

Ans. A software refers to instructions which when executed provide desired function and performance and data structures that enable the programs to adequately manipulate information, and documents describing the operation and the use of the software. It refers to set of instructions also known as program.

Characteristics of a good software :

a) Focuses on user’s actual needs.b) Does not expose its implementationc) Makes error hard.d) Uses graphical control propertye) Handles error carefullyf) Gives plenty of feedback.

The three characteristics of good application software are :- 1) Operational Characteristics

) Correctness: The software which we are making should meet all the specifications stated by the customer.b)  Usability/Learnability: The amount of efforts or time required to learn how to use the software should be less. This makes the software user-friendly even for IT-illiterate people.c) Integrity : Just like medicines have side-effects, in the same way a software may have a side-effect i.e. it may affect the working of another application. But a quality software should not have side effects.d)  Reliability : The software product should not have any defects. Not only this, it shouldn't fail while execution.e) Efficiency : This characteristic relates to the way software uses the available resources. The software should make effective use of the storage space and execute command as per desired timing requirements.f) Security : With the increase in security threats nowadays, this factor is gaining importance. The software shouldn't have ill effects on data / hardware. Proper measures should be taken to keep data secure from external threats.g) Safety : The software should not be hazardous to the environment/life.

2) Transition Characteristics

) Interoperability : Interoperability is the ability of software to exchange information with other applications and make use of information transparently.b) Reusability : If we are able to use the software code with some modifications for different purpose then we call software to be reusable.c)Portability : The ability of software to perform same functions across all environments and platforms, demonstrate its portability.

3) Revision Characteristics

a) Maintainability : Maintenance of the software should be easy for any kind of user. b) Flexibility : Changes in the software should be easy to make.c) Extensibility : It should be easy to increase the functions performed by it. d) Scalability : It should be very easy to upgrade it for more work(or for more number of users).e) Testability : Testing the software should be easy.f) Modularity : Any software is said to made of units and modules which are independent of each other. These modules are then integrated to make the final software. If the software is divided into separate independent parts that can be modified, tested separately, it has high modularity.

Q1. (b) Explain the linear sequential and RAD models of software process. State the advantages and limitations of each model.

Ans . Linear Sequential Model:

The simplest process model is the water fall model which states that the force is organized in a linear order. So it is also known as the linear sequential model or classic life style model. The linear sequential model is oldest and the most widely used paradigm for software engineering. Linear sequential model suggests a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing and maintenance.

 

Modeled after the conventional engineering cycle, the linear sequential model encompasses the following activities.

 

-      System / Information engineering and modeling

-      Software requirement analysis

-      Design

-      Code generation

-      Testing

-      Maintenance

 

1.      System / Information Engineering

Because software is always part of a larger system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software.

This view is essential when software must interface with other elements such as hardware, people, and databases. This provides Top-Level design and analysis.

 

2.      Software requirements analysis

The requirements gathering process is intensified and focused specifically on software.

Analysis is important for software engineer to understand the information domain for the software, required functions, behavior, performance, and interfacing.

Requirements for both the system and the software are documented and reviewed with the customer.

 

 

3.      Design

Software design is actually a multi-step process that focuses on data structure, software architecture, procedural detail and interface characterization.

The design process translates requirements into a representation of the software that can be assessed for quality before code generation begins.

The design documents must e prepared and stored as a part of software configuration.

 

4.      Code generation

The code generation step translates the design into a machine readable form. If design is performed in a detailed manner, code generation can be accomplished mechanistically.

 

5.      Testing

Once code has been generated, program testing begins. The testing process focuses on the logical internals of the software, assuring that all statements have been tested, and on the functional externals – that is, conducting test to uncover errors and ensure that defined input will produce actual results that agree with required results.

 

6.      Maintenance

Software will undergo change after it is delivered to the customer. Change will occur because, errors have been encountered or to accommodate changes in its external environment (e.g. change in device) or customer requires functional or peripheral enhancement.

Advantages:

Simple and systematic. Linear ordering clearly marks the end of the one phase and starting of another phase The output of particular phase will be input put for next phase there for this output are normally

referred as intermediate product or based line

  Limitations :

1)   Real projects rarely follow the sequential flow that the model proposes. Changes can cause confusion as the project team proceeds.

2)   It is difficult for the customer to state all requirements explicitly at the beginning of the projects.

3)   The water fall model assumes that the requirement should be completely specified before the rest of the development can proceed. In some situation it might be required that first developed a part of the system completely and then later enhance a system where the client face an important role in requirement specification.

4)   The customer must have patience. A working version of program(s) will not be available until late in the project time span.

5)   Development is often delayed unnecessarily. The linear nature of the classic life cycle leads to “Blocking state” in which some project team members must wait for other members of the team to complete dependent tasks.

6)   The time spent waiting can exceed the time spent on productive work

RAPID APPLICATION DEVELOPMENT (RAD) :

RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model the components or functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled into a working prototype.  This can quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements.

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.Data modeling: Information gathered from business modeling is used to define data objects that are needed for the business.Process modeling: Data objects defined in data modeling are converted to achieve the business information flow to achieve some specific business objective. Description are identified and created for CRUD of data objects.Application generation: Automated tools are used to convert process models into code and the actual system.Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

Reduced development time. Increases reusability of components Quick initial reviews occur Encourages customer feedback Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

Depends on strong team and individual performances for identifying business requirements. Only system that can be modularized can be built using RAD Requires highly skilled developers/designers. High dependency on modeling skills Inapplicable to cheaper projects as cost of modeling and automated code generation is very

high.

 When to use RAD model:

RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.

It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).

Q2. (a) Describe a structure of a SRS document with a suitable example.

SRS is a specification for a particular software product, program or set of programs that performs certain functions in a specific environment. It serves a number of purposes depending on who is writing it. First, the SRS could be written by the customer of a system. Second, the SRS could be written by the developer of the system. The scenarios create entirely different purposes for the document. First case, SRS is used to define the needs and expectations of the users. The second case, SRS is written for different purposes and serve as a contract document between the customer and developer.

Structure of SRS:

1 Introduction

1.1 Purpose

Comment: Purpose of the document and not the purpose of the software.

Example: This document provides all of the requirements for the yyy. Parts 1 and 2 are intended primarily for customers of the application, but will also be of interest to software engineers building or maintaining the software. Part 3 is intended primarily for software engineers, but will also be of interest to customers.

1.2 Scope

Comment: What aspects of the application this document tends to cover?

Example: This document covers the requirements for release xxx of yyy. Mention will be made throughout this document of selected probable features of future releases. The purpose of this is to guide developers in selecting a design that will be able to accommodate the full-scale application.

1.3 Definitions, Acronyms, and Abbreviations

Comment: Glossary of that will be used throughout the documents, as well as in other documents based on this one. Usually in the form of table.

1.4 References

Comment: References to all documents that are connected to this one.

Example: Software Project management Plan for yyy, version xxx (xxx is the vesrion of the document and not the version of the software). Software Design Description for yyy, version xxx.

1.5 Overview

Comment: Overview of the software. Its main goals, tasks and users.

2 Overall Description

Comment: Overall description of software - more detailed than in 1.5. This should be general enough so that it is unlikely to change much in future versions. Avoid statements that are repeated in later sections.

2.1 Product perspective

Comment: In this section software should be compared with other related or competing products, which is a good way to provide perspective of our product.

2.1.1 System interfaces

Comment: List all special interfaces to operating system.

2.1.2 User interfaces

Comment: Preliminary sketches and/or principles of key user interfaces only, used to provide perspective on the product. All user interfaces are described in detail in section 3.

2.1.3 Hardware interfaces

Comment: List all special hardware needed for software operation.

Example: Joystick will be used as an input device for some functions of the software (enlisted later).

2.1.4 Software interfaces

Comment: Interfaces with other software products.

2.1.5 Communication interfaces

Comment: List all communication interfaces.

Example: Modem will provide access to Internet when necessary.

2.1.6 Memory constraints

Comment: memory that is expected to be used by the software (external and internal).

Example: yyy is expected to use no more than 16 MB of Ram and 20 MB of external storage.

2.1.7 Operations

Comment: List all normal and special operations required by the user.

Example: It must be possible to save and retirev the current state of the software.

2.1.8 Site adaptation requirements

Comment: Requirements for execution on a particular installation

Example: User interface must exist in three different languages: Hungarian, Serbian, and Slovak.

2.2 Product functions

Comment: Summary of the major functions of the application. More detailed than section 1.5 but less detailed than section 3.

Example: Use case can be used to describe the main functions. If done so, then here all use cases can be briefly described (and displayed).

2.3 User characteristics

Comment: Indicate what kind of people the typical user are likely to be. For example: novice, software professional, accountant with 5 years of computer usage, etc.

2.4 Constraints

Comment: All conditions that may limit developer's options. These can originate from many sources.

Example: yyy shall operate on PCs running Windows 95 or later at a minimum speed of 100 MHZ. Java shall be the implementation language.

2.5 Assumptions and dependencies

Comment: Any assumptions being made.

Example: Future versions of yyy shall operate on PCs running Linux.

2.6 Apportioning of requirements

Comment: Order in which requirements are to be implemented.

Example: The requirements described in sections 1 and 2 of this document are referred to as preliminary specifications; those in section 3 are referred to as requirements (or functional) specifications. The two levels of requirements are intended to be consistent. Inconsistencies are to be logged as defects. In the event that a requirement is stated within both preliminary and functional specifications, the application will be built from functional specification since it is more detailed.

'Essential requirements' (referred to in section 3) are to be implemented for this version of yyy. 'Desirable requirements' are to be implemented in this release if possible, but are not committed to by the developers. It is anticipated that they will be part of future release. 'Optional requirements' will be implemented at the discretion of developers.

3 Specific requirements

3.1 External interface requirements

3.1.1 User interfaces

Comment: Description of user interface in section 2.1.2 showed only sketches of user interfaces in order to provide product perspective. It lacks details and should not be regarded as the last word. If user interfaces are not completely specified later in this document, then all details should be given in this section.

3.1.2 Hardware interfaces

Comment: Hardware that the software product deals with.

3.1.3 Software interfaces

Comment: Other software with which software product must interface.

3.1.4 Communication interfaces

Comment: Communication interfaces (Internet, modem, ...).

3.2 Classes/Objects

Comment: This style of SRS expects that detailed requirements are classified by classes. This section should list classes pertaining to the domain of the application and are adequate for organizing all of the requirements. These classes are not all of the classes that will be used by the application. Every function/class should be marked as 'essential', 'desirable', or 'optional'.

3.3 Performance requirements

Comment: Performance requirements include required speeds and/or time to complete. Unless documented in a different section of the SRS, they may also include memory usage (RAM and/or disk) noted either statically or dynamically (i.e., memory required at runtime).

3.4 Design constraints

Comment: Restrictions on design. If there is no material in this section, designers are free to create any (good) design that satisfies the requirements.

3.5 Software system attributes

3.5.1 Reliability

Example: yyy shall fail not more than once in a week. Reference to test documentation goes also here.

3.5.2 Availability

3.5.3 Security

Example: yyy shall ask for user-name and password at the beginning. Passwords will be encrypted before saving.

3.5.4 Maintainability

Comment: Lists of all functions/classes that are expected to change soon or to change frequently.

3.6 Other requirements

4 Supporting information

4.1 Table of Contents and Index

4.2 Appendices

Q2.(b) What is data flow diagram? Why is it used?

Ans. A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design).

On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process.

A DFD provides no information about the timing or ordering of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD). Data flow diagrams can be used in both Analysis and Design phase of the SDLC.

When it comes to conveying how information data flows through systems (and how that data is transformed in the process), data flow diagrams (DFDs) are the method of choice over technical descriptions for three principal reasons.

(1) DFDs are easier to understand by technical and nontechnical audiences.

(2) DFDs can provide a high level system overview, complete with boundaries and connections to other systems.

(3) DFDs can provide a detailed representation of system components.

Example:

Q3. How projects are estimated using SLOC, FP and COCOMO techniques?

Source lines of code (SLOC or LOC) is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or effort once the software is produced.

Measurement methods

There are two major types of SLOC measures: physical SLOC (LOC) and logical SLOC (LLOC). Specific definitions of these two measures vary, but the most common definition of physical SLOC is a count of lines in the text of the program's source code including comment

lines. Blank lines are also included unless the lines of code in a section consists of more than 25% blank lines. In this case blank lines in excess of 25% are not counted toward lines of code.

Logical LOC attempts to measure the number of "statements", but their specific definitions are tied to specific computer languages (one simple logical LOC measure for C-like programming languages is the number of statement-terminating semicolons). It is much easier to create tools that measure physical SLOC, and physical SLOC definitions are easier to explain. However, physical SLOC measures are sensitive to logically irrelevant formatting and style conventions, while logical   LOC is less sensitive to formatting and style conventions. Unfortunately, SLOC measures are often stated without giving their definition, and logical LOC can often be significantly different from physical SLOC.

Consider this snippet of C code as an example of the ambiguity encountered when determining SLOC:

for (i = 0; i < 100; i += 1) printf("hello"); /* How many lines of code is this? */

In this example we have:

1 Physical Lines of Code (LOC) 2 Logical Line of Code (LLOC) (for statement and printf statement) 1 comment line

Depending on the programmer and/or coding standards, the above "line of code" could be written on many separate lines:

for (i = 0; i < 100; i += 1){ printf("hello");} /* Now how many lines of code is this? */

In this example we have:

4 Physical Lines of Code (LOC): is placing braces work to be estimated? 2 Logical Line of Code (LLOC): what about all the work writing non-statement lines? 1 comment line: tools must account for all code and comments regardless of comment

placement.

Even the "logical" and "physical" SLOC values can have a large number of varying definitions. Robert E. Park (while at the Software Engineering Institute) et al. developed a framework for defining SLOC values, to enable people to carefully explain and define the SLOC measure used in a project. For example, most software systems reuse code, and determining which (if any) reused code to include is important when reporting a measure.

FUNCTION POINTS:

Function point measures functionality from the users point of view, that is, on the basis of what the user requests and receives in return from the system. The principle of functional point analysis iis that a system is decomposed into functional units.

Inputs – information entering the system Outputs – information leaving the system Enquiries – requests for instant access to information Internal Logical Files – Information held within the system External Interface files – Information held by other systems that is used by the system being

analyzed

Measurement Method:

Now to calculate the function points we need to follow the following steps:

1. Measure the application boundary a. The application boundary defines what is external to the application. b. It is dependent on the users external business view of the application and not on

the technical and/or implementation consideration

2. Identify the data functionalities (ILF and EIF) a. User identifiable group of data; logically related and maintained with in the

boundary of the application through one or more elementary process is know as ILF.

b. User identifiable group of data, logically related, referenced by the application but maintained with in the boundary of different application is known as EIF.

c. Few other terminologies of RET and DET are to be understood here as well to determine the function points.

d. A RET (record element type) is a user recognizable subgroup of data elements with as ILF or EIF

e. A DET (data element type) is a unique user recognizable, non-repeated field either maintained in an ILF or retrieved from an ILF or ELF.

3. Identify the transaction functionalities (EI, EO, EQ) a. All the tree Transactional functionalities are "elementary processes"

b. An Elementary Process is the smallest unit of activity that is meaningful to the user(s).

c. The elementary process must be self-contained and leave the business of the application in a consistent state.

d. An EI (External Input) is an elementary process of the application which processes data that enters from outside the boundary of the application. Maintains one or more ILF.

e. An EO (External Output) is an elementary process that generates data that exits the boundary of the application (i.e. presents information to the user) through processing logic, retrieval of data through ILF or EIF. The processing logic contains mathematical calculations, derived data etc.

f. An EQ (External Query) is an elementary process that results in retrieval of data that is sent outside the application boundary (i.e. present information to the user) through retrieval of data from ILF or EIF. The processing logic should not contain any mathematical formula, derived data etc.

4. Using the above data we can calculate the UFP (Unadjusted Function Points) a. After all the basic data & transactional functionalities of the system have been

defined we can use the following set of tables below to calculate the total UFP. b. Now for each type of Functionality determine the UFP's based on the below table. c. For EI's, EO's & EQ's determine the FTR's and DET's and based on that

determine the Complexity and hence the Number of UFP's it contributes. We have to calculate this for all the EI's, EO's & EQ's.

External Inputs (EI)

File Type Referenced (FTR)

">Data Elements (DET)

1-4 5-15 Greater than 15

Less than 2 Low (3) Low (3) Average (4) 2 Low (3) Average (4) High (6)

Greater than 2 Average (4) High (6) High (6)

External Outputs (EO)

">File Type Referenced (FTR)

">Data Elements (DET)

1-5 6-19 Greater than 19

Less than 2 Low (4) Low (4) Average (5) 2 or 3 Low (4) Average (5) High (7)

Greater than 3 High (7) High (7) High (7)

External Inquiry (EQ)

">File Type Referenced (FTR)

">Data Elements (DET)

1-5 6-19 Greater than 19

Less than 2 Low (3) Low (3) Average (4) 2 or 3 Low (3) Average (4) High (6)

Greater than 3 Average (4) High (6) High (6)

d. For ILF's & EIF's determine the RET's and DET's and based on that determine the Complexity and hence the Number of UFP's it contributes. We have to calculate this for all the ILF's & EIF's.

Internal Logical File (ILF)

">Record Element Types (RET)

">Data Elements (DET)

1-19 20-50 51 or More 1 RET Low (7) Low (7) Average (10)

2 to 5 RET Low (7) Average (10)

High (15)

6 or more RET Average (10)

High (15) High (15)

External Interface File (EIF)

">Record Element Types (RET)

">Data Elements (DET)

1-19 20-50 51 or More 1 RET Low (5) Low (5) Average (7)

2 to 5 RET Low (5) Average (7) High (10) 6 or more RET Average (7) High (10) High (10)

e. Once we have the score of all the Functionalities we can get the UFP as

UFP = Sum of all the Complexities of all the EI's, EO's EQ's, ILF's and EIF's

5. Further the calculation of VAF (Value added Factor) which is based on the TDI (Total Degree of Influence of the 14 General system characteristics)

a. TDI = Sum of (DI of 14 General System Characteristics) where DI stands for Degree of Influence.

b. These 14 GSC are

1. Data Communication

2. Distributed Data Processing

3. Performance

4. Heavily Used Configuration

5. Transaction Role

6. Online Data Entry

7. End-User Efficiency

8. Online Update

9. Complex Processing

10. Reusability

11. Installation Ease

12. Operational Ease

13. Multiple Sites

14. Facilitate Change

c. These GSC are on a scale of 0-5

6. Once the TDI is determined we can put it in the formula below to get the VAF.

VAF = 0.65 + (0.01 * TDI)

7. Finally the Adjusted Function Points or Function Points are

FP = UFP * VAF

8. Now these FP's can be used to determine the Size of the Software, also can be used to quote the price of the software, get the time and effort required to complete the software.

9. Effort in Person Month = FP divided by no. of FP's per month (Using your organizations or industry benchmark)

10. Schedule in Months = 3.0 * person-month^1/3

COCOMO Model:

COCOMO is a hierarchy of software cost estimation models, which include basic, intermediate and detailed sub models.

Basic : It aims at estimating in a quick and rough fashion, most of the small to medium sized software products. Three modes of software development are considered in this model: organic, semi – detached and embedded.

In the organic mode, a small team of experienced developers develop s software in a very familiar environment. The size of the software development in this mode ranges from small( a few KLOC) to medium ( a few tens of KLOC), while in other two modes the size ranges from small to very large( a few hundreds of KLOC)

In the embedded mode of software development, the project has tight constraints which might be related to the target processor and its interface with the associated hardware. The problem to be solved is unique and so it is often hard to find experienced persons as the same does not usually exist.

The semi – detached mode is an intermediate between the organic mode and embedded mode.

The Basic COCOMO equations take the form:

E = ab KLOC bb

D = cb E db

where E is the effort applied in person-months, D is the development time in chronological months and KLOC is the estimated number of delivered lines of code for the project (express in thousands). The coefficients ab and cb and the exponents bb and db are given in Table 1.

Basic COCOMO Model

Software Project ab bb cb db

organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

embedded 3.6 1.20 2.5 0.32

 

The basic model is extended to consider a set of "cost driver attributes" that can be grouped into four major categories:

1. Product attributes

a. required software reliability

b. size of application data base

c. complexity of the product

2. Hardware attributes

a. run-time performance constraints

b. memory constraints

c. volatility of the virtual machine environment

d. required turnaround time

3. Personnel attributes

a. analyst capability

b. software engineer capability

c.applications experience

d. virtual machine experience

e. programming language experience

4. Project attributes

a. use of software tools

b. application of software engineering methods

c. required development schedule

Each of the 15 attributes is rated on a 6 point scale that ranges from "very low" to "extra high" (in importance or value). Based on the rating, an effort multiplier is determined from tables published by Boehm , and the product of all effort multipliers results is an effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.

The intermediate COCOMO model takes the form:

E = ai KLOC bi x EAF

where E is the effort applied in person-months and KLOC is the estimated number of delivered lines of code for the project. The coefficient ai and the exponent bi are given in Table 2.

INTERMEDIATE COCOMO MODEL

Software project ai bi

organic 3.2 1.05

Semi-detached 3.0 1.12

embedded 2.8 1.20

COCOMO represents a comprehensive empirical model for software estimation.

Q4. (a) What are the reasons of delay of a software project? How can these delays be prevented?

Ans. The following are few of the reasons of delays of a software project:

1. Expansion of functionalityThe expansion of functionality is a phenomenon in which new functionalities continue to be conceived and requested as the project proceeds. The software can never be completed in this way.

2. Gold platingGold plating is a phenomenon in which programmers and designers try to make many details of the software or design too elaborate. Much time is spent improving details, even though the improvements were not requested by the customer or client. The details often add little to the desired result.

3. Neglecting quality controlTime pressure can sometimes cause programmers or project teams to be tempted to skip testing. This frequently causes more delays than it prevents. The time that elapses before an error is discovered in the software is associated with an exponential increase in the time that is needed to repair it.

4. Overly optimistic schedulesOverly optimistic schedules place considerable pressure on the project team. The team will initially attempt to reach the (unrealistic) deadlines. These attempts lead to sloppy work and more errors, which cause further delays.         In this regard, be particularly wary of schedules that are imposed from above. The desire to complete a project (more) quickly sometimes arises for primarily strategic reasons; if it is not feasible, however, it should not be attempted. The project will not proceed more quickly and the product will ultimately suffer.

5. Working on too many projects at the same timeDividing work across many different projects (or other tasks) causes waiting times that lead to many delays in projects.

6. Poor designThe absence (or poor realisation) of designs leads to delays, as it requires many revisions at later stages.

7. The 'one-solution-fits-all' syndromeUsing the right software for a project is important. Some software platforms are more suited to particular applications than others are. Thinking that the use of particular software will greatly improve productivity, however, is also a trap.

8. Research-oriented projectsProjects in which software must be made and research must be conducted are difficult to manage. Research is accompanied by high levels of uncertainty. When or if progress will be achieved in research is unclear. When software development is dependent upon the results of research, the former frequently comes to a standstill.

9. Mediocre personnelInsufficiently qualified personnel can cause project delays. Technically substantive knowledge of the subject of the project plays a role, as do knowledge and skills in working together to play the game of the project.

10. Customers fail to fulfil agreementsCustomers are not always aware that they are expected to make a considerable contribution to the realisation of a project. When customers do not react in a timely manner to areas in which they must be involved, projects can come to a standstill. Worse yet, the team may proceed further without consulting the customer, which can lead to later conflicts.

11. Tension between customers and developersThe tension that can arise between customers and developers (e.g. because the project is not proceeding quickly enough) can cause additional delays, as it disturbs the necessary base of trust and the working atmosphere.

How to avoid Delays:

People participate in various projects, including projects at work, school and home. These projects often take weeks, months or years to complete, depending upon schedules, materials,

costs and complications. People involved in the projects have to save or raise money, coordinate workers and purchase supplies while working on the project. Finding ways to stick to schedules, coordinate activities and deal with unexpected problems helps to ensure you don't have delays that cause your project to be a failure.

1. Project Planning and Implementation

o Come up with a method for completing your plan that is feasible given your timeframe, workforce, resources and funding. Have clear goals for the project so you know what you wish to accomplish with the project. Your project plan should outline the different phases of the project and the timeframe for completing each segment. Brainstorm with group members when developing a project plan. Think about the needs and wishes of the people, organization or groups for which you are completing the project, if you are not the recipient of the final product, according to Project Smart.

When working on the project, stick to the original plan as much as possible, and be prepared to alter your plan as unexpected problems arise. Organize workers in such a way that you can maximize how much work gets completed at a given time and make sure that others are staying on task. Appoint people as supervisors or group leaders to coordinate activities, deal with issues with workers and troubleshoot when complications come up, if you are unable to take on the role of project supervisor or are dealing with a large group of people. Regularly communicate with other group members using telephone calls, emails, text messages and other forms of communication, so that each phase of a project goes off smoothly.

2. Schedule

o Develop a master schedule that outlines how long you expect to take to finish the project. Account for the time it will take to raise or save money, work on each phase of the project, and purchase and move materials when you develop a schedule. Also consider time periods when you won't be able to work on the project. Use paper or computer documents, such as a Word or Excel document, to keep track of work that you have accomplished and need to do. Also, use documents to keep track of everyone's schedule. Be prepared to revise your master and weekly schedules due to unexpected events, including those in people's lives. When you get off your schedule, work harder and for longer hours to make up for time lost and prevent extended delays.

3. Costs

o Plan for project costs from the start of the project, taking worker and material costs into account. Do research on what materials and services cost to develop a basic estimate of project costs. Find out what different materials and services you

will need for the project by talking to experts or others who have worked on similar projects to come up with an estimate. When you start to spend money on the project, keep track of your costs to ensure that you have enough money to complete the project. Find ways to get additional funding through bank loans, investors or personal funds ahead of time if your project has unexpected costs. Purchase good materials, but do not choose luxury items if you don't have the funding.

Complications

o Be prepared for or anticipate possible complications ahead of time, if possible. Include potential solutions in your initial or revised plan for problems that could arise during the implementation phase. Talk to people who have done similar projects to avoid making the same mistakes, or prepare an emergency plan for potential complications. When you have problems within your project, come up with and implement solutions in a timely manner so you don't experience time delays. Consult different resources, including experts, to find out how to deal with the problem in the most efficient manner.

Q5. A) How is Gantt chart used in software project management?

Gantt chart:

A Gantt chart, commonly used in project management, is one of the most popular and useful ways of showing activities (tasks or events) displayed against time. On the left of the chart is a list of the activities and along the top is a suitable time scale. Each activity is represented by a bar; the position and length of the bar reflects the start date, duration and end date of the activity. This allows you to see at a glance:

What the various activities are When each activity begins and ends How long each activity is scheduled to last Where activities overlap with other activities, and by how much The start and end date of the whole project

To summarize, a Gantt chart shows you what has to be done (the activities) and when (the schedule).

A simple Gantt chart

b) What is Rayleigh curve?

Ans. The Norden /Rayleigh equation, represents manpower, measured in persons per unit time as a function of time. It is usually expressed in person-year/year (PY/YR). The Rayleigh curve is modeled by the differential equation:

Q6.a) What are the various types of testing strategy?

Ans. Software testing must be planned carefully to avoid wasting development time and resources. Testing begins “in the small” and progresses “to the large”. Initially individual components are tested and debugged. After the individual components have been tested and added to the system, integration testing takes place. Once the full software product is completed, system testing is performed. The Test Specification document should be reviewed like all other software engineering work products.

Strategic Approach to Software Testing

Many software errors are eliminated before testing begins by conducting effective technical reviews

Testing begins at the component level and works outward toward the integration of the entire computer-based system.

Different testing techniques are appropriate at different points in time. The developer of the software conducts testing and may be assisted by independent

test groups for large projects. Testing and debugging are different activities. Debugging must be accommodated in any testing strategy.

Verification and Validation

Make a distinction between verification (are we building the product right?) and validation (are we building the right product?)

Software testing is only one element of Software Quality Assurance (SQA) Quality must be built in to the development process, you can’t use testing to add

quality after the fact

Organizing for Software Testing

The role of the Independent Test Group (ITG) is to remove the conflict of interest inherent when the builder is testing his or her own product.

Misconceptions regarding the use of independent testing teamso The developer should do no testing at allo Software is tossed “over the wall” to people to test it mercilesslyo Testers are not involved with the project until it is time for it to be tested

The developer and ITGC must work together throughout the software project to ensure that thorough tests will be conducted

Software Testing Strategy

Unit Testing – makes heavy use of testing techniques that exercise specific control paths to detect errors in each software component individually

Integration Testing – focuses on issues associated with verification and program construction as components begin interacting with one another

Validation Testing – provides assurance that the software validation criteria (established during requirements analysis) meets all functional, behavioral, and performance requirements

System Testing – verifies that all system elements mesh properly and that overall system function and performance has been achieved

Strategic Testing Issues

Specify product requirements in a quantifiable manner before testing starts. Specify testing objectives explicitly. Identify categories of users for the software and develop a profile for each. Develop a test plan that emphasizes rapid cycle testing. Build robust software that is designed to test itself. Use effective formal reviews as a filter prior to testing. Conduct formal technical reviews to assess the test strategy and test cases. Develop a continuous improvement approach for the testing process.

Unit Testing

Module interfaces are tested for proper information flow. Local data are examined to ensure that integrity is maintained. Boundary conditions are tested. Basis (independent) path are tested. All error handling paths should be tested. Drivers and/or stubs need to be developed to test incomplete software.

Integration Testing

Sandwich testing uses top-down tests for upper levels of program structure coupled with bottom-up tests for subordinate levels

Testers should strive to indentify critical modules having the following requirements Overall plan for integration of software and the specific tests are documented in a

test specification

Integration Testing Strategies

Top-down integration testing

1. Main control module used as a test driver and stubs are substitutes for components directly subordinate to it.

2. Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach).

3. Tests are conducted as each component is integrated.4. On completion of each set of tests and other stub is replaced with a real

component.5. Regression testing may be used to ensure that new errors not introduced.

Bottom-up integration testing1. Low level components are combined into clusters that perform a specific

software function.2. A driver (control program) is written to coordinate test case input and output.3. The cluster is tested.4. Drivers are removed and clusters are combined moving upward in the program

structure.

Regression testing – used to check for defects propagated to other modules by changes made to existing program1. Representative sample of existing test cases is used to exercise all software

functions.2. Additional test cases focusing software functions likely to be affected by the

change.3. Tests cases that focus on the changed software components.

Smoke testing1. Software components already translated into code are integrated into a build.2. A series of tests designed to expose errors that will keep the build from

performing its functions are created.3. The build is integrated with the other builds and the entire product is smoke

tested daily (either top-down or bottom integration may be used).

General Software Test Criteria

Interface integrity – internal and external module interfaces are tested as each module or cluster is added to the software

Functional validity – test to uncover functional defects in the software Information content – test for errors in local or global data structures Performance – verify specified performance bounds are tested

Object-Oriented Test Strategies

Unit Testing – components being tested are classes not modules Integration Testing – as classes are integrated into the architecture regression tests

are run to uncover communication and collaboration errors between objects Systems Testing – the system as a whole is tested to uncover requirement errors

Object-Oriented Unit Testing smallest testable unit is the encapsulated class or object similar to system testing of conventional software do not test operations in isolation from one another driven by class operations and state behavior, not algorithmic detail and data flow

across module interface

Object-Oriented Integration Testing

focuses on groups of classes that collaborate or communicate in some manner integration of operations one at a time into classes is often meaningless thread-based testing – testing all classes required to respond to one system input

or event use-based testing – begins by testing independent classes (classes that use very

few server classes) first and the dependent classes that make use of them cluster testing – groups of collaborating classes are tested for interaction errors regression testing is important as each thread, cluster, or subsystem is added to the

system

WebApp Testing Strategies

1. WebApp content model is reviewed to uncover errors.2. Interface model is reviewed to ensure all use-cases are accommodated.3. Design model for WebApp is reviewed to uncover navigation errors.4. User interface is tested to uncover presentation errors and/or navigation mechanics

problems.5. Selected functional components are unit tested.6. Navigation throughout the architecture is tested.7. WebApp is implemented in a variety of different environmental configurations and

the compatibility of WebApp with each is assessed.8. Security tests are conducted.9. Performance tests are conducted.10.WebApp is tested by a controlled and monitored group of end-users (looking for

content errors, navigation errors, usability concerns, compatibility issues, reliability, and performance).

Validation Testing

Focuses on visible user actions and user recognizable outputs from the system Validation tests are based on the use-case scenarios, the behavior model, and the

event flow diagram created in the analysis modelo Must ensure that each function or performance characteristic conforms to its

specification.o Deviations (deficiencies) must be negotiated with the customer to establish a

means for resolving the errors. Configuration review or audit is used to ensure that all elements of the software

configuration have been properly developed, cataloged, and documented to allow its support during its maintenance phase.

Acceptance Testing

Making sure the software works correctly for intended user in his or her normal work environment.

Alpha test – version of the complete software is tested by customer under the supervision of the developer at the developer’s site

Beta test – version of the complete software is tested by customer at his or her own site without the developer being present

System Testing

Series of tests whose purpose is to exercise a computer-based system The focus of these system tests cases identify interfacing errors Recovery testing – checks the system’s ability to recover from failures Security testing – verifies that system protection mechanism prevent improper

penetration or data alteration Stress testing – program is checked to see how well it deals with abnormal resource

demands (i.e. quantity, frequency, or volume) Performance testing – designed to test the run-time performance of software,

especially real-time software Deployment (or configuration) testing – exercises the software in each of the

environment in which it is to operate

Q6. b) How is software quality ensured using SEI-CMM?

Ans.

Q7. What is statistical Quality Assurance(SQA)? Develop your own metrics for correctness, maintainability, integrity and usability of the software?

Ans. The statistical quality assurance is application of statistical principle and techniques in all stages of production, design, maintenance and services, directed toward the economic satisfaction of demand. The statistical quality assurance is a system of application that embraces all formal quantitative aspect of planning, design, purchase, production, services, marketing and re-design of product, it helps to find problems to state them in meaningful terms and to solve them, it provides a plan, a road-map, that leads to better competitive position. The great advantages of statistical thinking are that it allows managers to differentiate between common causes and special causes of trouble .

Q8.(a) How is risk reduction different from risk mitigation?