Software Engineering for MBA 3rd Semester Bnagalore University

8/21/2019 Software Engineering for MBA 3rd Semester Bnagalore University

1/33

1) Coupling:Measures the strength of all relationships between functional units

Of the two properties, coupling is easier to measure and understand,

because it is more mechanical in nature and requires less interpretation. Suppose there are three

components A, B, and C. As behavior depends upon B in some way (any way), As behavior

depends upon C in some way, and the behavior of B and C do not appear to depend upon

anything else. Thats pretty much it, thats the coupling of the system according to our definition,

and its the sort of thing that a machine can figure out by simple measurement.

2) Why Software engineering called as a layered technology?

Software engineering encompasses a

A) Tool:provide automated or semi-automated support for the process and the methods.B) Method:provide the technical fo building software. Methods encompass a broad array of

tasks that include requirements analysis, design, program construction, testing, and

support.

C) Process:Process defines a framework for a set of key process areas that must beestablished for effective delivery of software engineering

D) A quality focus:Any engineering approach must rest on an quality.

3) Encapsulation:Wrapping up data member and method together into a single unit.Encapsulation is like your bag in which you can keep your pen, book etc. It means this is

the property of encapsulating members and functions.Encapsulation means hiding the internal details of an object, i.e. how an object does

something.

Polymorphism:polymorphism means one kind of object can look like another kind ofobject.

4) Software Reengineering: It is a process of software development which is done to

improve the maintainability of a software system.

Software Re-engineering is the examination and alteration of a system to reconstitute it

in a new form

This process encompasses a combination of sub-processes such as reverse engineering,

restructuring, redocumentation, forward engineering, and retargeting.

5) SDLC: SDLC is the process consisting of a series of planned activities to develop or alter

the software products.

Analysis, Design, Implementation, Testing, Evolution

6) Top-Down integration:The top-down approach to integration testing requires thehighest-level modules be test and integrated first. This allows high-level logic and data

flow to be tested early in the process and it tends to minimize the need for drivers.


2/33

However, the need for stubs complicates test management and low-level utilities are

tested relatively late in the development cycle. Another disadvantage of top-down

integration testing is its poor support for early release of limited functionality.

7) Software Maturity Index(SMI): SMI can be a measurement of product stability, whenSMI approaches 1.0 the product is stable.

SMI = (M - (A + C + D)) / MM = number of modules in current version

A = number of added modules in current version

C = number of changed modules in current version

D = number of deleted modules in current version compared to the previous version

8) Umbrella activities of in software engineering: Umbrella activities are defined by a

set of tasks that are adapted to the project type and degree of rigor with which software

engineering is to be applied.

The umbrella activities in a software development life cycle process include the following:

Software Project Management

Formal Technical Reviews

Software Quality Assurance Software Configuration Management

Re-usability Management

Risk Management

Measurement and Metrics

Document Preparation and Production

9) PERTactivities are shown as a network of precedence relationships using activity-on-arrow network construction.

Multiple time estimates

Probabilistic activity times

USED IN: Project management - for non-repetitive jobs (research and

development work), where the time and cost estimates tend to be quite uncertain.

This technique uses probabilistic time estimates.

CPM:activities are shown as a network of precedence relationships using activity-on-node network construction

Single estimate of activity time

Deterministic activity times

USED IN: Production management - for the jobs of repetitive in nature where the

activity time estimates can be predicted with considerable certainty due to the

existence of past experience.

10)System Decommissioning:The System Decommissioning Phase of the SystemDevelopment Life Cycle may be initiated by various events. In some cases, the Project

may lose funding and is terminated, in others, a planned shutdown (decommission) may

be initiated. The process defined, and templates provided here are based on thesuccessful execution of a planned shutdown where the process was defined and managed

as a stand-alone project. In this case, a System Decommission occurred because the

client base was migrated to a sister application/platform.

Taking the system out of service after the end of its useful operation lifetime.


3/33

11)List out the metrics for specifying non-functional requirement:

Time: Transactions / sec, Response time, Time to complete an operation

Space: Main memory, Auxiliary memory, (Cache)

Usability: Training time, Number of choices, Mouse clicks

Reliability: Mean time to failure, Downtime probability, Failure rate, Availability

Robustness: Time to recovery, % of incidents leading to catastrophic failures, Datacorruption probability after a failure

Portability: % of non-portable code, Number of systems where software can run

12)Work Breakdown:o A hierarchical list of work activities needed to complete the project; a description

of the work to be performed broken down to its key components, down to the

lowest level.o Divide and conquer levelo Work breakdown structure identifies activities at a level useful for selecting the

team with the proper skills.o Based on staff number and estimates for the work breakdown structure, schedule

cost and duration can be estimated.

13)Product Risk: Product risk is the risk associated with the software or system, thepossibility that software or system may fail to satisfy end user/customers

expectations is known as product risk.

There may be the possibility that the software or system does not have the

functionality specified by the customer or the stakeholders which leads to

unsatisfactory software

Unsatisfactory software has risk and has the possibility of failure which can cause

major functional damage.

Low quality software can have many problems like functionality, reliability, usability

or performance.

14)Architectural design:Concept that focuses on thecomponents orelements of

astructure orsystem and unifies them into a coherent andfunctional whole,according to a particular approach in achieving the objective(s) under the

givenconstraints orlimitations.

15)System Testing:is the testing of behavior of a complete and fully integratedsoftware product based on the software requirements specification (SRS)

document. In main focus of this testing is to evaluate Business / Functional / End-

user requirements.This is black box type of testing where external working of the software is evaluated with

the help of requirement documents & it is totally based on Users point of view. For this

type of testing do not required knowledge of internal design or structure or code.

This testing is to be carried out only after System Integration Testing is completed where

bothFunctional & Non-Functional requirements are verified.

16)Smoke testing:Smoke testing is the initial testing process exercised to check whether

the software under test is ready/stable for further testing.

17)Bottom-Up integration:each component at lower hierarchy is tested individually; thenthe components that rely upon these are tested.

Test B, C individually (using drivers)
http://www.businessdictionary.com/definition/concept.htmlhttp://www.businessdictionary.com/definition/concept.htmlhttp://www.businessdictionary.com/definition/component.htmlhttp://www.businessdictionary.com/definition/element.htmlhttp://www.businessdictionary.com/definition/structure.htmlhttp://www.businessdictionary.com/definition/system.htmlhttp://www.businessdictionary.com/definition/functional.htmlhttp://www.businessdictionary.com/definition/constraint.htmlhttp://www.businessdictionary.com/definition/limitation.htmlhttp://www.softwaretestingclass.com/http://www.softwaretestingclass.com/http://www.businessdictionary.com/definition/limitation.htmlhttp://www.businessdictionary.com/definition/constraint.htmlhttp://www.businessdictionary.com/definition/functional.htmlhttp://www.businessdictionary.com/definition/system.htmlhttp://www.businessdictionary.com/definition/structure.htmlhttp://www.businessdictionary.com/definition/element.htmlhttp://www.businessdictionary.com/definition/component.htmlhttp://www.businessdictionary.com/definition/concept.html


4/33

Test A such that it calls B

If an error occurs we know that the problem is in A or in the interface between A and B

Test A such that it calls C

If an error occurs we know that the problem is in A or in the interface between A and C

18)Difference Verification and Validation:

Verification Validation

1. Verification is a static practice of

verifying documents, design, code and

program.

1. Validation is a dynamic mechanism

of validating and testing the actual

product.

2. It does not involve executing the

code.

2. It always involves executing the

code.

3. It is human based checking of

documents and files.

3. It is computer based execution of

program.

4. Verification uses methods like

inspections, reviews, walkthroughs,

and Desk-checking etc.

4. Validation uses methods like black

box (functional) testing, gray box

testing, and white box (structural)

testing etc.

5. Verification is to check whether the

software conforms to specifications.

5. Validation is to check whether

software meets the customer

expectations and requirements.

6. It can catch errors that validation

cannot catch. It is low level exercise.

6. It can catch errors that

verification cannot catch. It is High

Level Exercise.

7. Target is requirements specification,

application and software architecture,

high level, complete design, and

database design etc.

7. Target is actual product-a unit, a

module, a bent of integrated modules,

and effective final product.

8. Verification is done by QA team to

ensure that the software is as per the

specifications in the SRS document.

8. Validation is carried out with the

involvement of testing team.

9. It generally comes first-done

before validation.

9. It generally follows after verification.

19)Embedded Software:Beyond simple input/output data transformation, embeddedsoftware is built into the electronics of devices we use every day - cars, phones, TVs,

appliances, health monitoring equipment, etc. - to control these systems' interactions

with the physical world. Embedded software thus becomes more complex as applications

become more sophisticated in systems such as planes, missiles, and process control

systems. Developers must consider timeliness, concurrency, liveness, reactivity, and

heterogeneity when programming abstractions. Types of embedded software include

operating systems such as embedded Linux, Windows Embedded, and Real-Time


5/33

Operating Systems (RTOSs), which are intended for real-time applications and designed

to be very compact and efficient, forsaking many functions that non-embedded computer

operating systems provide. Communication protocols designated for embedded systems

can be closed or open source.

20)Boundary value analysis: Boundary value analysis (BVA) is based on testing at the

boundaries between partitions.Here we have both valid boundaries (in the valid partitions) and invalid boundaries (in the

invalid partitions).

As an example, consider a printer that has an input option of the number of copies to be

made, from 1 to 99. To apply boundary value analysis, we will take the minimum and

maximum (boundary) values from the valid partition (1 and 99 in this case) together with

the first or last value respectively in each of the invalid partitions adjacent to the valid

partition (0 and 100 in this case). In this example we would have three equivalence

partitioning tests (one from each of the three partitions) and four boundary value tests.

Consider the bank system described in the previous section in equivalence partitioning.

21)Software Metric:

Code

Static

Dynamic

Programmer productivity

Design

Testing

Maintainability

Management

Cost

Duration, time

Staffing

22)Risk Identification:Risk identification is the process of determining risks that could

potentially prevent the program, enterprise, or investment from achieving its objectives.

It includes documenting and communicating the concern.

23)Characteristics of a software: Software costs are concentrated in engineering (analysis and design) and not in

production.

Cost of software is not dependent on volume of production.

Software does not wear out (in the physical sense).

Software has no replacement (spare) parts.

Software maintenance is a difficult problem and is very different from hardware

(physical product) maintenance.

Most software are custom-built.

Many legal issues are involved (e.g. intellectual property rights, liability).

24)Software Models: usedhttp://istqbexamcertification.com/what-are-the-software-

development-models/
http://istqbexamcertification.com/what-are-the-software-development-models/http://istqbexamcertification.com/what-are-the-software-development-models/http://istqbexamcertification.com/what-are-the-software-development-models/http://istqbexamcertification.com/what-are-the-software-development-models/http://istqbexamcertification.com/what-are-the-software-development-models/http://istqbexamcertification.com/what-are-the-software-development-models/


6/33

Waterfall Model (Linear sequential model, Classic life cycle model): It is very simple

to understand and use. In a waterfall model, each phase must be completed fully before the next

phase can begin.

Requirement->Design->Implementation->Verification->Maintenance

V Model:V- model means Verification and Validation model. Just like thewaterfall model,the V-

Shaped life cycle is a sequential path of execution of processes.

Incremental model: In incremental model the whole requirement is divided into various

builds. Multiple development cycles take place here, making the life cycle amulti-waterfall

cycle. Cycles are divided up into smaller, more easily managed modules. Each module passes

through the requirements, design, implementation andtesting phases.

RAD Model:Rapid application development:RAD is incremental software developmentprocess model that allows usable systems to be built in as little as 60-90 days.

The RAD model used for information systems development.

It is a type ofincremental 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 thenassembled into a working prototype.
http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-a-software-testing/http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-a-software-testing/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/


7/33

Agile model:Software is developed in incremental, rapid cycles. This results in small

incremental releases with each release building on previous functionality. Each release isthoroughlytested to ensuresoftware quality is maintained. It is used for time critical

applications.

Iterative model: An iterative life cycle model does not attempt to start with a fullspecification of requirements. Instead, development begins by specifying and implementing

just part of the software, which can then be reviewed in order to identify further requirements.

This process is then repeated, producing a new version of the software for each cycle of the

model.

Spiral Model(Boehms Spiral Model):The spiral model is similar to theincremental model,

with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk

Analysis, Engineering and Evaluation. A software project repeatedly passes through thesephases in iterations (called Spirals in this model). The baseline spiral, starting in the planning

phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the

baseline spiral. Requirementsare gathered during the planning phase. In the risk analysis

phase, a process is undertaken to identify risk and alternate solutions. A prototype is

produced at the end of the risk analysis phase.

Advantages of Spiral model:

High amount of risk analysis hence, avoidance of Risk is enhanced.
http://istqbexamcertification.com/why-is-testing-necessary/http://istqbexamcertification.com/what-is-software-quality/http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/http://istqbexamcertification.com/what-is-software-quality/http://istqbexamcertification.com/why-is-testing-necessary/


8/33

Good for large and mission-critical projects.

Strong approval and documentation control.

Additional Functionality can be added at a later date.

Software is produced early in thesoftware life cycle.

Disadvantages of Spiral model:

Can be a costly model to use.

Risk analysis requires highly specific expertise.

Projects success is highly dependent on the risk analysis phase.

Doesnt work well for smaller projects.

When to use Spiral model:

When costs and risk evaluation is important

For medium to high-risk projects

Long-term project commitment unwise because of potential changes to economic priorities

Users are unsure of their needs

Requirements are complex

New product line

Significant changes are expected (research and exploration)

Prototype model:The basic idea here is that instead of freezing the requirements before a

design or coding can proceed, a throwaway prototype is built to understand the requirements.

This prototype is developed based on the currently known requirements. By using this

prototype, the client can get an actual feel of the system, since the interactions with

prototype can enable the client to better understand the requirements of the desired system.
http://istqbexamcertification.com/what-are-the-software-development-life-cycle-phases/http://istqbexamcertification.com/what-are-the-software-development-life-cycle-phases/http://istqbexamcertification.com/what-are-the-software-development-life-cycle-phases/http://istqbexamcertification.com/what-are-the-software-development-life-cycle-phases/


9/33

25)Three Ps in s/w management project:-The three Ps are people management,Performance management and process management

Four Ps in s/w management project:-People, Process, Product, Project

26)CMM(Process maturity Level):Capability Maturity Model: Provides guidance on how togain control of processes for developing and maintaining software and how to evolve toward a

culture of software engineering and management excellence.

Maturity level indicates level of process capability:

o Initial

o Repeatable

o Defined

o Managed

o Optimizing

27)Software Quality Assurance: A Software Quality Assurance Engineer is involved in theentire software development process to ensure the quality of the final product. This can

include processes such as requirements gathering and documentation, source code control,

code review, change management, configuration management, release management and the

actual testing of the software. Software QA is often confused withSoftware Testing,but should

not be. Testing is a big part of Software Quality Assurance, but it is not, by any means, the

only part of it.

Umbrella activity applied throughout the software process

Planned and systematic pattern of actions required to ensure high quality in software

Responsibility of many stakeholders (software engineers, project managers, customers,salespeople, SQA group)

28)Alpha Beta Testing:Its best to provide customers with an outline of the things that youwould like them to focus on and specific test scenarios for them to execute.Provide with customers who are actively involved with a commitment to fix defects that theydiscover.

29)Defect Removal Efficiency (DRE): he defect removal efficiency (DRE) gives a measure ofthe development team ability to remove defects prior to release. It is calculated as a ratio ofdefects resolved to total number of defects found. It is typically measured prior and at the

moment of release.DRE= Number of defects resolved by the development team / total number of defects at themoment of measurement.DRE is typically measured at the moment of version release, the best visualization is just toshow current value of DRE as a number.

30)UML(UnifiedModelingLanguage)UML is a standard language for specifying, visualizing, constructing, and documenting theartifacts of software systems.UML was created by Object Management Group (OMG) and UML 1.0 specification draft was

proposed to the OMG in January 1997.OMG is continuously putting effort to make a truly industry standard.

UML stands for Unified Modeling Language. UML is different from the other common programming languages like C++, Java,

COBOL etc. UML is a pictorial language used to make software blue prints.

So UML can be described as a general purpose visual modeling language to visualize, specify,construct and document software system. Although UML is generally used to model softwaresystems but it is not limited within this boundary. It is also used to model non softwaresystems as well like process flow in a manufacturing unit etc.UML is not a programming language but tools can be used to generate code in variouslanguages using UML diagrams. UML has a direct relation with object oriented analysis anddesign. After some standardization UML is become an OMG (Object Management Group)standard.
http://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htmhttp://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htmhttp://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htmhttp://jobsearchtech.about.com/od/careersintechnology/p/SWTest.htm


10/33

31)Abstraction and Interfaces: An interface cannot implement any methods, whereas an abstract class can A class can implement many interfaces but can have only one superclass (abstract or

not)

An interface is not part of the class hierarchy. Unrelated classes can implement the

same interface

Syntax:

abstract class:

public class Apple extends Food { }

interface:

public class Person implements Student, Athlete, Chef { }

32)Design Pattern: It is a description or template for how to solve a problem that can be usedin many different situations.Types: Creational Design Patterns, Behavioral Design Patterns, Structural Design Patterns

33)Unit Testing and Integration Testing:Unit Testing:Algorithms and logic, Data structures (global and local),Interfaces,Independent paths, Boundary conditions, Error handling

Integration Testing: One module can have an adverse effect on another

Sub functions, when combined, may not produce the desired major function Individually acceptable imprecision in calculations may be magnified to unacceptable

levels

8 Marks Question Answer1)

Alpha Testing Beta Testing (Field Testing)

1. It is always performed by the developers

at the software development site.

1. It is always performed by the customers

at their own site.

2. Sometimes it is also performed by

Independent Testing Team.

2. It is not performed by Independent

Testing Team.

3. Alpha Testing is not open to the market

and public

3. Beta Testing is always open to the market

and public.

4. It is conducted for the software

application and project.

4. It is usually conducted for software

product.

5. It is always performed in Virtual

Environment.

5. It is performed in Real Time

Environment.

6. It is always performed within the

organization.

6. It is always performed outside the

organization.

7. It is the form of Acceptance Testing. 7. It is also the form of Acceptance Testing.

8. Alpha Testing is definitely performed and

carried out at the developing organizations

location with the involvement of

developers.

8. Beta Testing (field testing) is performed

and carried out by users or you can say

people at their own locations and site using

customer data.

9. It comes under the category of both

White Box Testing and Black Box Testing.

9. It is only a kind of Black Box Testing.


11/33

10. Alpha Testing is always performed at

the time of Acceptance Testing when

developers test the product and project to

check whether it meets the user

requirements or not.

10. Beta Testing is always performed at the

time when software product and project are

marketed.

11. It is always performed at thedevelopers premises in the absence of the

users.

11. It is always performed at the userspremises in the absence of the development

team.

12. Alpha Testing is not known by any

other different name.

12 Beta Testing is also known by the

name Field Testingmeans it is also known

as field testing.

13. It is considered as the User Acceptance

Testing (UAT) which is done at developers

area.

13. It is also considered as the User

Acceptance Testing (UAT) which is done at

customers or users area.

Scenario-based testing: is used for writing tests for individual user scenario, which would check

their work. Scenarios concentrate on the principal objectives and requirements. If thescenario runs from start to finish, then it passes.

2) Need and Features of requirement analysis of software engineering:

Requirement analysis:A process of discovery, refinement, modeling, and specification.During the process, both the developers and customers take an active role.

Need of requirement analysis:Analyzing, Documenting, Validating and Managing

Features of requirement analysis of software:Problem recognition (or system understanding)

- Discover and understand the system requirements- Refine the requirements

Evaluation and synthesis:- what are the alternative solutions

- focus on what solution should be selected or usedinstead of how to implement a solution.

Modeling: to represent the various aspects of the system

- the required data- information and control flow

- operation behaviorSpecification of:

- software functions, and performance- interfaces between system elements

- system constraints

Requirements Analysis Process:- Domain understanding:

- Understanding of application domain.

- Requirements collections:- The process of interacting with customers, users to discoverthe requirements for the system.

- Requirements classification:

- Group and classify the gathered requirements.- Conflict resolution:


12/33

- Resolve the conflict requirements.

- Prioritization:

- Identify and list requirements according to their importance- Requirements validation:

- Check and validate the gathered requirements to seeif they are complete, correct, and sound

3) Various reasons why the software projects fails:

Specific methodology

INTERDEPENDENT FACTORS: Cost, quality, speed, and riskDATA MIGRATION & IMPLEMENTATION

Inexperienced project managers

Inexperienced DeveloperLack of Team SupportLack of Software

Lack of communication

Lack of management supportFixed project completion dateDeveloper estimates are too optimistic

The project scope changesFive Level of the SEI-CMM Frame Work:Capability Maturity Model is a bench-mark formeasuring the maturity of an organizations software process. It is a methodology used to

develop and refine an organizations software development process. CMM can be used to

assess an organization against a scale of five process maturity levels based on certain KeyProcess Areas (KPA). It describes the maturity of the company based upon the project thecompany is dealing with and the clients. Each level ranks the organization according to its

standardization of processes in the subject area being assessed.A maturity model provides:

A place to start The benefit of a communitys prior experiences A common language and a shared vision

A framework for prioritizing actions

A way to define what improvement means for your organization

In CMMI models with a staged representation, there are five maturity levels designated bythe numbers 1 through 5 as shown below:

Initial

Managed


13/33

Defined

Quantitatively Managed

Optimizing

4) Software Metrics and different approaches of developing software metrics:

Software Metrics:

Quantitative measurements distilled from data

Distilled by measuring software development processes and actual source code

Highlight areas that need work in specific nodes of code as well as generalizations about your code

overall.

Approaches of developing of software metrics:

Lines of code Number of classes & interfaces

Code to comment ratio

Cyclomatic complexity:

Directly measures the number of linearly independent paths through source code

CC = E - N + p

If code contains no decisions, then CC=1, if a piece of code contains a binary if statement, CC=2,

etc...

Code coverage

Function coverage - Has each function in the program been executed?

Statement coverage - Has each line of the source code been executed?

Condition coverage - Has each evaluation point (such as a true/false decision) been executed?Path coverage - Has every possible route through a given part of the code been executed?

Entry/exit coverage - Has every possible call and return of the function been executed

Bugs to lines of code ratio

Cohesion

Cohesion is a measure of how strongly-related the various responsibilities of a software module are

A node is usually deemed to have "high cohesion" or "low cohesion"


14/33

High Cohesion can indicate many things about code, including the extent of reuse of code and

readability

Coupling

Coupling is the extent to which a node relies on the other nodes in the source code

Nodes can be called either "loosely/weakly coupled" or "strongly/tightly coupled"

Loose coupling indicates high cohesion!

Loose coupling refers to a relationship between nodes such that one node interacts with the other

nodes via a stable interface and does not need be concerned with the internal implementation of the

other nodes

Types of coupling:

a. Content coupling (tightest) - is when one node modifies or relies on the internal

workings of another node

b. Common coupling - is when nodes share the same global data

c. External coupling - Is when nodes rely on an external data format

d. Data coupling - Is when nodes share data through parameters

e. Message coupling (loosest) - Is when modules are not dependent on each other, they

use a public interface to communicate

Failed tests per build

Version control commits per day

Lines of code per commit

5) Project Plan in Software Engineering: Project planning is a discipline for stating how to

complete a project within a certain timeframe, usually with defined stages, and with designated

resources.

a) Project Goals

The project sponsor.

The customer who receives the deliverables.

The users of the project outputs. The project manager and project team.

b) Project Deliverables

c) Project Schedule

d) Making supporting plans

o Human Resource Plan

o Communications Plan

o Risk Management Plan

Time and cost estimates too optimistic.

Customer review and feedback cycle too slow.

Unexpected budget cuts.

Unclear roles and responsibilities. Stakeholder input is not sought, or their needs are not properly

understood.

Stakeholders changing requirements after the project has started.

A stakeholder adding new requirements after the project has started.

Poor communication resulting in misunderstandings, quality problems

and rework.

Lack of resource commitment.


15/33

6) Possible software risk: Risks are identified, classified and managed before actual execution ofprogram. These risks are classified in different categories.

Categories of risks:

Schedule Risk:

Project schedule get slip when project tasks and schedule release risks are not addressed properly.

Schedule risks mainly affect on project and finally on company economy and may lead to project

failure.

Schedules often slip due to following reasons:

Wrong time estimation

Resources are not tracked properly. All resources like staff, systems, skills of individuals etc.

Failure to identify complex functionalities and time required to develop those functionalities.

Unexpected project scope expansions.

Budget Risk:

Wrong budget estimation.

Cost overruns

Project scope expansion

Operational Risks:

Risks of loss due to improper process implementation, failed system or some external events risks.

Causes of Operational risks:

Failure to address priority conflicts

Failure to resolve the responsibilities

Insufficient resources

No proper subject training

No resource planning

No communication in team.

Technical risks:

Technical risks generally leads to failure of functionality and performance.

Project Risk:

Business Risk:

Known Risk:

Predictable Risk:

Unpredictable Risk:

7) Cost Estimation techniques used in software engineering

There is no simple way to make an accurate estimate of the effort required to develop a software

system

Initial estimates are based on inadequate information in a user requirements definition

Project cost estimates may be self-fulfilling

The estimate defines the budget and the product is adjusted to meet the budgetEstimation techniques

o Algorithmic cost modelling

A formulaic approach based on historical cost information and which is generally based on the

size of the software

has example formula E = a + bNc

where


16/33

E is the effort estimate

N is the estimate or measure being used as the basis for the effort estimate (e.g. number of use

casesor lines of code)

a, b and c are obtained by extensive analysis of past projects and comparisons with the current

project

Note: Explain COCOMO Model:

o Expert judgement

One or more experts in both software development and the application domain use their

experience to predict software costs. Process iterates until some consensus is reached.

Advantages: Relatively cheap estimation method. Can be accurate if experts have direct

experience of similar systems

Disadvantages: Very inaccurate if there are no experts!

o Estimation by analogy

The cost of a project is computed by comparing the project to a similar project in the same

application domain

Advantages: Accurate if project data available

Disadvantages: Impossible if no comparable project has been tackled. Needs systematically

maintained cost databaseo Parkinson's Law

The project costs whatever resources are available

Advantages: No overspend

Disadvantages: System is usually unfinished

o Pricing to win The project costs whatever the customer has to spend on it

Advantages: You get the contract

Disadvantages: The probability that the customer gets the system he or she wants is small. Costs

do not accurately reflect the work required

o Top-down and bottom-up estimation Top-down

Start at the system level and assess the overall system functionality and how this isdelivered through sub-systems

Bottom-up

Start at the component level and estimate the effort required for each component. Add

these efforts to reach a final estimate

8) Quality assurance and standards for achieving software quality:

Software quality assurance:

Software quality assurance is an integral part of the software development lifecycle. Its aim is to verify

the quality of a program based upon provided software specifications. It is the responsibility of the

software testing team to carry out the proper tests necessary to ensure a project meets businessrequirements from a functional and user perspective. QA is also encouraged to provide input in regards

to overall usability, flow and even aesthetics.

Type of testing: Unit Testing, Integration Testing, Regression Testing, User Acceptance Testing (UAT),

Performance and Load Testing.

9) Black box testing and white box testing (Please See Software 4PDF)Black box testing:


17/33

Specification-based testing technique is also known as black-box or input/output driven testing

techniques because they view the software as a black-box with inputs and outputs.

The testers have no knowledge of how the system or component is structured inside the box. In

black-box testing the tester is concentrating on what the software does, not how it does it.

The definition mentions both functional and non-functional testing. Functional testing is

concerned with what the system does its features or functions. Non-functional testing isconcerned with examining how well the system does. Non-functional testing like performance,

usability, portability, maintainability, etc.

Specification-based techniques are appropriate at all levels of testing (component testing

through to acceptance testing) where a specification exists. For example, when performing

system or acceptance testing, the requirements specification or functional specification may

form the basis of the tests.

There are four specification-based or black-box techniques:

Equivalence partitioning

Boundary value analysis

Decision tables

State transition testing

White box testing:

Structure-based testing technique is also known as white-box or glass-box testing technique

because here the testers require knowledge of how the software is implemented, how it works.

In white-box testing the tester is concentrating on how the software does it. For example, a

structural technique may be concerned with exercising loops in the software.

Different test cases may be derived to exercise the loop once, twice, and many times. This may

be done regardless of the functionality of the software.

Structure-based techniques can also be used at all levels of testing. Developers use structure-

based techniques in component testing and component integration testing, especially where

there is good tool support for code coverage.

Structure-based techniques are also used in system and acceptance testing, but the structuresare different. For example, the coverage of menu options or major business transactions could

be the structural element in system or acceptance testing.

Test Plan:A test plan can be defined as a document describing the scope, approach, resources,

and schedule of intended testing activities. It identifies test items, the features to be tested, the

testing tasks, who will do each task, and any risks requiring contingency planning.

In software testing, a test plan gives detailed testing information regarding an upcoming testing

effort, including

Scope of testing

Schedule

Test Deliverables

Release Criteria

Risks and Contingencies

It is also be described as a detail of how the testing will proceed, who will do the testing, what will

be tested, in how much time the test will take place, and to what quality level the test will be

performed.

10)Object Oriented Process Model:


18/33

Object--oriented development:

Object--oriented analysis, design and programming are related but distinct.

OOA is concerned with developing an object model of the application domain.

OOD is concerned with developing an object--oriented system model to implement

requirements.

OOP is concerned with realizing an OOD using an OO programming language such as Java or C++

Objects and object classes: Objects are entities in a software system which represent instances of

real--world and system entities.

Object classes are templates for objects. They may be used to create objects.

Object classes may inherit attributes and services from other object classes.

The Unified Modeling Language: The Unified Modeling Language is an integration of these

notations.

It describes notations for a number of different models that may be produced during OO analysis and

design.

Employee

name: string

address: string

dateOfBirth: DateemployeeNo: integer

socialSecurityNo: string

department: Dept

manager: Employee

salary: integer

status: {current, left, retired}

taxCode: integer

join ()

leave ()

retire ()

changeDetails ()Object communication:In practice, messages are often implemented by procedure calls

Name = procedure name;

Information = parameter list

Generalization and inheritance:Generalization in the UML is implemented as inheritance in OO

programming languages.

UML associations: Associations may be annotated with information that describes the association.

Associations are general but may indicate that an attribute of an object is an associated object or that a

method relies on an associated object.


19/33

An object--oriented design process: Structured design processes involve developing a number

of different system models.

They require a lot of effort for development and maintenance of these models and, for small systems,

this may not be cost--effective.

However, for large systems developed by different groups design models are an essential

communication mechanism.

11) Throwaway Prototyping and Evolutionary Prototyping:

Throwaway prototypingis :

Developed from an outline of a specification, an various prototypes are delivered and modified

until the client is satisfied with its functionality. Throwaway prototyping is where the objective of the evolutionary development process is to

understand the customer's requirements and hence develop a better requirements definition

for the system. The prototype concentrates on experimenting with the customer requirements

that are poorly understood.

This approach extends the requirements analysis process with the intention of reducing overall

lige cycle costs.

Customers and end-users should resist the temptation to turn the throw-away prototyping into

a delivered system that is put into use.

Evolutionary prototypes:

Built from basic requirements gathered from end-users. An initial prototype is presented to theusers and evaluated. The prototype is modified based on the feedback until the client is

satisfied.

Exploratory development where the objective of the process is to work with the customer to

explore their requirements and deliver a final system. The development starts with the parts of

the system that are understood. The system evolves by adding new features proposed by the

customer.

There are three main problems with evolutionary prototyping which are particularly important

when large,

long-lifetime systems are to be developed

Difficulties do not mean that evolutionary prototyping should be rejected.

12) Software Characteristics (McCalls Quality Factor):A software product must meet all

the requirements of the customer or end-user. Also, the cost of developing and maintaining the

software should be low. The development of software should be completed in the specified time-frame.

The three characteristics of good application software are :-

1) Operational Characteristics

2) Transition Characteristics

3) Revision Characteristics


20/33

Operation: Correctness, Usability/Learnability, Integrity, Reliability, Efficiency , Security , Safety

Transition: Usability, Portability, Transferability

Revision: Maintainability, Testability, Flexibility, Extensibility, Scalability, Modularity

13) Essential attributes of software product:Following factors are used to measure software development quality. Each attribute can be used to

measure the product performance. These attributes can be used for Quality assurance as well as Quality

control. Quality Assurance activitiesare oriented towards prevention of introduction of defects

and Quality control activitiesare aimed at detecting defects in products and services.

Reliability :Measure if product is reliable enough to sustain in any condition. Should give consistently

correct results.Product reliability is measured in terms of working of project under different working

environment and different conditions.

Maintainability :Different versions of the product should be easy to maintain. For development its

should be easy to add code to existing system, should be easy to upgrade for new features and new

technologies time to time. Maintenance should be cost effective and easy. System be easy to maintain

and correcting defects or making a change in the software.

Usability:This can be measured in terms of ease of use. Application should be user friendly. Shouldbe easy to learn. Navigation should be simple.The system must be:Easy to use for input preparation, operation, and interpretation of output.Provide consistent user interface standards or conventions with our other frequently used systems.Easy for new or infrequent users to learn to use the system.Portability:This can be measured in terms of Costing issues related to porting, Technical issuesrelated to porting, Behavioral issues related to porting.

Correctness:Application should be correct in terms of its functionality, calculations used internallyand the navigation should be correct. This means application should adhere to functionalrequirements.Efficiency:To Major system quality attribute. Measured in terms of time required to complete anytask given to the system. For example system should utilize processor capacity, disk space andmemory efficiently. If system is using all the available resources then user will get degraded

performance failing the system for efficiency. If system is not efficient then it can not be used in realtime applications.Integrity or security: Integrity comes with security. System integrity or security should be sufficientto prevent unauthorized access to system functions, preventing information loss, ensure that thesoftware is protected from virus infection, and protecting the privacy of data entered into the system.Testability:System should be easy to test and find defects. If required should be easy to divide indifferent modules for testing.Flexibility: Should be flexible enough to modify. Adaptable to other products with which it needsinteraction. Should be easy to interface with other standard 3rd party components.


21/33

Reusability: Software reuse is a good cost efficient and time saving development way. Different codelibraries classes should be generic enough to use easily in different application modules. Dividingapplication into different modules so that modules can be reused across the application.Interoperability: Interoperability of one system to another should be easy for product to exchange

data or services with other systems. Different system modules should work on different operatingsystem platforms, different databases and protocols conditions.Applying above quality attributes standards we can determine whether system meets the

requirements of quality or not.

14) Measures of software Quality:There are many measures of software quality, correctness;maintainability, integrity, and usability provide useful indicators for the project team.Correctness:

Correctness is the degree to which the software performs its required function. The most common measure for correctness is defects per KLOC, where a defect is defined as a

verified lack of conformance to requirements. When considering the overall quality of a software product, defects are those problems

reported by a user of the program after the program has been released for general use. For quality assessment purposes, defects are counted over a standard period of time, typically

one year.Maintainability:1) Maintainability is the ease with which a program can be

Corrected if an error is encountered,

Adapted if its environment changes, or

Enhanced if the customer desires a change in requirements

2) There is no way to measure maintainability directly; therefore, we must use indirect measures.3) A simple time-oriented metric is mean-time-to change (MTTC), the time it takes to

Analyze the change request,

Design an appropriate modification,

Implement the change, test it, and

Distribute the change to all users.

On average, programs that are maintainable will have a lower MTTC (for equivalent

types of changes) than programs that are not maintainable.

Integrity:

1. This attribute measures a system's ability to withstand attacks (both accidental and intentional)

to its security.

2. Attacks can be made on all three components of software: programs, data, and documents.

3. To measure integrity, two additional attributes must be defined:

Threat

Security.

4. Threat is the probability (which can be estimated or derived from empirical evidence) that an

attack of a specific type will occur within a given time.

5. Security is the probability (which can be estimated or derived from empirical evidence) that the

attack of a specific type will be repelled.6. The integrity of a system can then be defined as

Integrity = summation [(1threat) * (1security)]

Where threat and security are summed over each type of attackUsability:

If a program is not user-friendly, it is often doomed to failure, even if the functions that it

performs are valuable.


22/33

Usability is an attempt to quantify user-friendliness and can be measured in terms of four

characteristics:

(1) The physical and or intellectual skill required to learn the system,

(2) The time required to become moderately efficient in the use of the system,

(3) The net increase in productivity measured when the system is used by someone who

is moderately efficient, and(4) A subjective assessment of users attitudes toward the system.

15) Business Process Re-engineering (BPR) :

It combines aspects of re-engineering and business process outsourcing, and rationalizes them to return

value in a short span of time. This, of course, maximizes long-term prospects for your business.

Business Process Re-engineering (BPR) solutions that assist you to fundamentally rethink and redesign

how your organization will meet its strategic objectives. We emphasize on innovation, flexibility, quality

service delivery, and cost control by re-engineering business methods and supporting processes using

state-of-the-art BPR tools and methodologies.

Business Process re-engineering services address your need to leverage newer technology platforms,

frameworks, and software products to transform IT systems and applications. Our Business Process Re-

engineering applications help you:

Scale up to handle a larger user base

Effectively address operational or performance issues with current application portfolio

Achieve a higher degree of maintainability

Alleviate licensing and support issues with the older technologies

Improve user friendliness and portability of applications

Reduce costs associated with maintaining old and poorly documented legacy system

A typical BPR project consists of the following main stages:

Identify business processes

Review, update & analyze as-is business processes

Design to-be business processes

Test & implement to-be business processes

16) Traits of software Manager:-

Hire People I Actually Want To Work With

Don't Micromanage

Always Follow-up On Your Promises

Have Excellent Business Domain Knowledge

Have Excellent Technical Skills

Create And Maintain Excellent Relationships

Care About Me As An Individual

Participate In Team Social Activities

Be A Process Champion

Have Boundless Energy17) Challenges for Real-Time Software Design:

A real-time system is a software system where the correct functioning of the system depends onthe results produced by the system and the time at which these results are produced

A soft real-time system is a system whose operation is degraded if results are not producedaccording to the specified timing requirements

A hard real-time system is a system whose operation is incorrect if results are not producedaccording to the timing specification


23/33

Challenges:Realtime Response:During the architecture design phase, the hardware and software engineers work

together to select the right system architecture that will meet the requirements. This involves deciding interconnectivity of the processors, link speeds, processor speeds, etc.The main questions to be asked are:

Is the architecture suitable?

Are the link speeds adequate?

Are the processing components powerful enough?

Is the Operating System suitable?

Recovering from Failures: Internal failures can be due to hardware and software failures in the system. The

different types of failures you would typically expect are:

Software Failures in a Task:

Processor Restart:

Board Failure:

Link Failure

Working with Distributed Architectures:Most Realtime systems involve processing on several different

nodes. The system itself distributes the processing load among several processors. This introduces several

challenges in design:

Maintaining Consistency: Initializing the System.

Inter-Processor Interfaces:

Load Distribution:

Centralized Resource Allocation

Asynchronous Communication: Remote procedure calls (RPC) are used in computer systems to simplify

software design. RPC allows a programmer to call procedures on a remote machine with the same semantics

as local procedure calls. RPCs really simplify the design and development of conventional systems, but they

are of very limited use in Realtime systems. The main reason is that most communication in the real world is

asynchronous in nature, i.e. very few message interactions can be classified into the query response paradigm

that works so well using RPCs.

Race Conditions and Timing:All the steps in a protocol are described with exact timing specification for each

stage. Most protocols will also specify how the timing should vary with increasing load. Realtime systems deal

with timing issues by using timers. Timers are started to monitor the progress of events. If the expected event

takes place, the timer is stopped. If the expected event does not take place, the timer will timeout and recovery

Establ ish systemrequirements

Partitionrequirements

Hardwarerequirements

Hardwaredesign

Softwarerequirements

Softwaredesign


24/33

action will be triggered.A race condition occurs when the state of a resource depends on timing factors that

are not predictable.

18) COCOMO Model(Constructive Cost Model):The Constructive Cost Model (COCOMO) is analgorithmic software cost estimation model developed by Barry Boehm. The model uses a basic regression

formula, with parameters that are derived from historical project data and current project characteristics.COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first level, Basic

COCOMO is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy is

limited due to its lack of factors to account for difference in project attributes (Cost Drivers). Intermediate

COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally accounts for the influence

of individual project phases.Basic COCOMO computes software development effort (and cost) as a function of

program size. Program size is expressed in estimated thousands of lines of code (KLOC)

COCOMO applies to three classes of software projects:

* Organic projects - "small" teams with "good" experience working with "less than rigid" requirements

* Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than

rigid requirements

* Embedded projects - developed within a set of "tight" constraints (hardware, software, operational, ...)

The basic COCOMO equations take the form

Effort Applied = ab(KLOC)bb [ man-months ]

Development Time = cb(Effort Applied)db [months]

People required = Effort Applied / Development Time [count]

The coefficients ab, bb, cb and db are given in the following table.

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

Basic COCOMO is good for quick estimate of software costs. However it does not account for differences in

hardware constraints, personnel quality and experience, use of modern tools and techniques, and so on.

Intermediate COCOMO computes software development effort as function of program size and a set of "cost

drivers" that include subjective assessment of product, hardware, personnel and project attributes. This

extension considers a set of four "cost drivers",each with a number of subsidiary attributes:

* Product attributes

Required software reliability

Size of application database

Complexity of the product

* Hardware attributes

Run-time performance constraints

Memory constraints

Volatility of the virtual machine environment

Required turnabout time

* Personnel attributesAnalyst capability

Software engineering capability

Applications experience

Virtual machine experience

Programming language experience
http://www.ifi.uzh.ch/req/courses/seminar_ws02/reports/Seminar_4.pdfhttp://www.ifi.uzh.ch/req/courses/seminar_ws02/reports/Seminar_4.pdf


25/33

* Project attributes

Use of software tools

Application of software engineering methods

Required development schedule

DIFFERENCES BETWEEN COCOMO I AND COCOMO II

The major differences between COCOMO I AND COCOMO II are:

COCOMO'81 requires software size in KDSI as an input, but COCOMO II is based on KSLOC (logicalcode). The major difference between DSI and SLOC is that a single Source Line of Code may be

several physical lines. For example, an "if-then-else" statement would be counted as one SLOC, but

might be counted as several DSI.

COCOMO II addresses the following three phases of the spiral life cycle: applications development,

early design and post architecture

COCOMO'81 provides point estimates of effort and schedule, but COCOMO II provides likely ranges

of estimates that represent one standard deviation around the most likely estimate.

The estimation equation exponent is determined by five scale factors (instead of the three

development modes)

Changes in cost drivers are:

1. Added cost drivers (7): DOCU, RUSE, PVOL, PLEX, LTEX, PCON, SITE

2. Deleted cost drivers (5): VIRT, TURN, VEXP, LEXP, MODP3. Alter the retained ratings to reflect more up-do-date software practices

Data points in COCOMO I: 63 and COCOMO II: 161

COCOMO II adjusts for software reuse and reengineering where automated tools are used for

translation of existing software, but COCOMO'81 made little accommodation for these factors

COCOMO II accounts for requirements volatility in its estimates

19) Functional and Non-Functional Requirements

Functional Requirements

These are statement of services the system should provide, how the system should react to particular

inputs and how the system should behave in particular situations.

In some cases, the functional requirements may also explicitly state what the system should not do.

These requirements depend on the type of software being developed, the expected users of thesoftware and the general approach taken by the organization when writing requirements.

When expressed as user requirements, the requirements are usually described in a fairly abstract way.

Functional system requirements describe the system in detail, its inputs and outputs, exceptions, and

so on.

In principle, the functional requirements specification of a system should be both complete and

consistent. Completeness means that all services required by the user should be defined. Consistency

means that requirements should not have contradictory definitions.

For example, here are examples of functional requirements for a university library system called

LIBSYS, used by the students and faculty to order books and documents from other libraries.

a) The user shall be able to search either all of the initial set of databases or select a subset from

it.b) The system shall provide appropriate viewers for the user to read documents in the

document store.

c) Every order shall be allocated a unique identifier (ORDER_ID), which the user shall be copy to

the documents permanent storage area.

Non Functional Requirements


26/33

These are constraints on the services or functions offered by the system.

They are not directly concerned with the specific functions delivered by the system.

They include timing constraints, constraints on the development process and standards.

They may relate to emergent system properties such as reliability, response time and store

occupancy. Alternatively, they may define constraints on the system such as the capabilities of I/O

devices and the data representations used in system interfaces.

Non-functional requirements often apply to the system as a whole. They do not usually just apply to

individual system features or services.

Failing to meet a non-functional requirement can mean that the whole system is unusable.

For e.g., if an aircraft system does not meet its reliability requirements, it will not be certified as safe for

operation; if a real-time control system fails to meet its performance requirements, the control functions

will not operate correctly.

Non-functional requirements arise through user needs, because of budget constraints, because of

organizational policies, because of the need for interoperability with other software or hardware

systems, or because of external factors such as safety regulations or privacy legislation.

The types of non-functional requirements

a) Product Requirements

These requirements specify product behavior.

Examples include performance requirements on how fast the system must execute and how much

memory it requires.

1. Reliability requirements that set out the acceptable failure rate.

2. Portability requirements and usability requirements.

For example

The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.

b) Organizational Requirements

1. These requirements are derived from policies and procedures in the customers and developers

organization.

2. Implementation requirements such as the programming language or design method used.

3. Delivery requirements that specify when the product and its documentation are to be delivered.For example

The system development process and deliverable documents shall conform to the process and

deliverables

defined in XYZCo-SP-STAN-95.

c)External Requirements1. This broad heading covers all requirements that are derived from factors external to the

system and its development process.

2. They may include interoperability requirements that define how the system interacts with

systems in other organizations.

3. Legislative requirements that must be followed to ensure that the system operates within the

law.

4. Ethical requirements that the system which is developed will be acceptable to its users andthe general public.

For example

The system shall not disclose any personal information about system users apart from their name and

library reference number to the library staff who use the system.

Domain Requirements


27/33

1. These requirements that come from the application domain of the system and that reflect

characteristics and constraints of that domain.

2. They may be functional or non-functional requirements.

3. Domain requirements are derived from the application domain of the system rather than

from the specific needs of the system users.

4. They usually include specialized domain terminology or reference to domain concepts.

5. They may be new functional requirements in their own right, constrain existing functionalrequirements or set out how particular computations must be carried out.

6. Because these requirements are specialized, software engineers often find it difficult to

understand how they are related to other system requirements.

7. Domain requirements are important because they often reflect fundamental of the

application domain.

8. If these requirements are not satisfied, it may be impossible to make the system work

satisfactorily.

20) Documentation Standards in a software projects:

Low-Risk Project Documentation

The goal is to communicate and document the essence of the project, primarily for

informational purposes, both within the University and to outside stakeholders.

TheLow-Risk Project Form provides a template for providing this information.

A low-risk project is typically described by a sentence or two of text in each of the sections of

the form.

The level of detail in this documentation should be agreed upon mutually by the project

manager and the project sponsor, with additional input and guidance as appropriate from the

key project stakeholders.

Medium-Risk Project Documentation

Documentation for medium-risk projects should be more detailed than for low-risk projects and

the level of detail should be commensurate with the complexity of the project in any case.

You are strongly encouraged to use project planning software, e.g., Microsoft Project, in

assembling the project plan and schedule.

The project plan should include a Scope Plan, which includes the project objectives and theproject deliverables, and which includes at least a simpleWork Breakdown Structure.

The Resource and Staffing Plan should indicate clearly the resources to be used and should

indicate key or required staff.

The Communication Strategy should articulate the extent and nature of communications

involved in the project.

The Budget Plan should be appropriate to the needs of the Project Sponsor.

The Security Plan should identify anticipated security issues and indicate how they will be

addressed.

The Testing Plan should be consistent with the complexity of the project and the associated

risks.

A Training Plan, if appropriate, should outline plans for training of all anticipated and intendedusers.

High-Risk Project Documentation

Documentation for high-risk projects should provide all of the information required to initiate,

plan, execute, monitor, and complete the project in a timely and cost-effective manner.

The documentation should follow the guidelines of the Project Management Body of Knowledge

(PMBOK)of the Project Management Institute.
http://www.itplanning.org.vt.edu/pm/lowrisk.htmlhttp://www.itplanning.org.vt.edu/pm/terms.html#wbshttp://en.wikipedia.org/wiki/PMBOKhttp://en.wikipedia.org/wiki/PMBOKhttp://www.itplanning.org.vt.edu/pm/terms.html#wbshttp://www.itplanning.org.vt.edu/pm/lowrisk.html


28/33

You are strongly encouraged to use project planning software, e.g., Microsoft Project, in

assembling the project plan and schedule.

A detailed Scope Document should be included that clearly describes the project objectives and

the project deliverables.

Plans for scope management should be provided and include procedures for change control.

The Resource and Staffing Plan should explain what resources (people, equipment, materials)and what quantities of each should be used to perform project activities, and it should provide a

complete account of key or required staff.

The Communication Plan should describe the processes required to ensure timely and

appropriate generation, collection, dissemination, storage, and ultimate disposition of project

information.

The Budget Plan should be appropriate to the needs of the Project Sponsor and should provide a

complete accounting of costs for staffing, equipment, software, supplies, consulting, and other

costs. A life cycle cost or total cost of ownership, projected out at least 5 years, should be

included.

The Security Plan should identify anticipated security issues and indicate how they will be

addressed.

The Testing Plan should be consistent with the complexity of the project and the associated

risks.

A Training Plan, if appropriate, should outline plans for training of all anticipated and intended

users.

21) Principles software project scheduling: Compartmentalization

The project must be compartmentalized into a number of manageable activities, actions, andtasks; both the product and the process are decomposed

Interdependency The interdependency of each compartmentalized activity, action, or task must be determined Some tasks must occur in sequence while others can occur in parallel

Some actions or activities cannot commence until the work product produced by another isavailable

Time allocation Each task to be scheduled must be allocated some number of work units In addition, each task must be assigned a start date and a completion date that are a function

of the interdependencies Start and stop dates are also established based on whether work will be conducted on a full-

time or part-time basis Effort validation

Every project has a defined number of people on the team As time allocation occurs, the project manager must ensure that no more than the allocated

number of people have been scheduled at any given time Defined responsibilities

Every task that is scheduled should be assigned to a specific team member

Defined outcomes Every task that is scheduled should have a defined outcome for software projects such as a

work product or part of a work product Work products are often combined in deliverables

Defined milestones Every task or group of tasks should be associated with a project milestone A milestone is accomplished when one or more work products has been reviewed for quality

and has been approved


29/33

22) Software Requirement Analysis: Determining the needs or conditions to meet for a new or altered product, In other words, process of studying and analyzing the customer and the user/stakaholder needs to

arrive at a definition of software reqiurements. Requirements must be actionable, measurable, testable, related to identified business needs or

opportunities, and defined to a level of detail sufficient for system design. Requirements can befunctional andnon-functional.

Types of Requirements Functional requirements Performance requirements

Speed, accuracy, frequency, throughput External interface requirements Design constraints

Requirements are usually about what, this is ahow. Quality attributes

i.e. reliability, portability, maintainability, supportability

Software Quality Attributes Correctness

Reliability Rating = 1(Num Errors/ Num LOC) Can be allocated to subsystems

Efficiency Integrity Usability Survivability Maintainability Verifiability Flexibility Portability Reusability Interoperability Expandability

Requirements Analysis:Defining User Profiles

Description - of the user type Type - qualify expertise, technical background, degree of sophistication Responsibilities - users key resp.s w.r.t. system being developed Success Criteria - how this user defines success? rewarded? Involvement - How user involved in this project? what role? Deliverables - Are there any deliverables the user produces? For whom? Comments/Issues - Problems that interfere w/ success, etc.

Defining User Work Environment Number of people involved in doing this now? Changing? How long is a task cycle now? Changing? Any unique environmental constraints: mobile, outdoors, in-flight, etc. Which system platforms are in use today? future? What other applications are in use? Need to integrate?

Product Overview Put the product in perspective to other related products and the users environment. Independent? Component of a larger system? How do the subsystems interact with this? Known interfaces between them and this component? Block diagram

Other Product Requirements hardware platform requirements -- system requirements -- supported host o.s.s, peripherals, companionsoftware
http://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Functional_requirementshttp://en.wikipedia.org/wiki/Requirement


30/33

environmental requirements -- temperature, shock, humidity, radiation, usage conditions, resourceavailability, maintenance issues, type of error recovery

applicable standards -- legal, regulatory, communications

Software Requirement Specification Asoftware requirements specification(SRS) is a complete description of the behavior of the system to

be developed

A document that clearly and precisely describes, each of the essential requirements of the softwareand the external interfaces.

(functions, performance, design constraint, and quality attributes) Each requirement is defined in such a way that its achievement is capable of being objectively verified

by a prescribed method; for example inspection, demonstration, analysis, or test.2

Requirements Analysis Fundamental Techniques (Views) functional view

hierarchy -function tree process use cases information ow data flow diagram (DFD)

data oriented view data structures data dictionary (DD), syntax diagram, Jackson diagram relations between entities entity relationship diagram (ER)

object-oriented viewclass structure class diagram

algorithmic view control structures pseudo code, structogram, flow diagram, Jackson diagram conditions rules, decision table

state-oriented view state machines Petri nets

sequence charts

Use Case use case is a description of a systems behavior as it responds to a request that originates

from outside of that system.

it describes "who" can do "what" with the system in question

Use Case Diagram A use case diagram

in theUnified Modeling Language(UML)

a type of behavioral diagram defined by and created from aUse-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in

terms ofactors,their goals (represented asuse cases), and any dependencies between thoseuse cases.

The main purpose to show what system functions are performed for which actor. Roles of the actors in the system can be depicted.
http://en.wikipedia.org/wiki/Software_requirements_specificationhttp://en.wikipedia.org/wiki/Software_requirements_specificationhttp://en.wikipedia.org/wiki/Software_requirements_specificationhttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Use-case_analysishttp://en.wikipedia.org/wiki/Use-case_analysishttp://en.wikipedia.org/wiki/Use-case_analysishttp://en.wikipedia.org/wiki/Actor_%28UML%29http://en.wikipedia.org/wiki/Actor_%28UML%29http://en.wikipedia.org/wiki/Actor_%28UML%29http://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Actor_%28UML%29http://en.wikipedia.org/wiki/Use-case_analysishttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Software_requirements_specification


31/33

Data Flow Diagram (DFD) graphical representation of data ow (classical technique) nodes:

function labeled circle store name between two horizontal lines interface to environmentlabeled rectangle

directed edges: represent data flow

properties of DFDs easy to create easy to read and understand

23) Ten software standard (ISO-9001) for effective software Q.A

1) Process:It is critical that the organization defines a process that is robust and certified by experts in order to

initiate the software assurance quality culture. The process will serve as a guideline that may evolve over time.Most importantly, it should be made official and should be followed through. Improvements will be made until amature process is established.

2) Managerial Commitment:Managerial commitment should stem from the CIO to ensure alignment from eachof the development managers, as well as from the development areas of each country. Everyone must beaware of the value that is added by testing & QA to the business. The process, therefore, must account for thevalue of the solutions that it offers to the organization.

3) Personal Experience:Hiring someone as a tester that lacks necessary experience is a common mistake. It is

vital to acknowledge that the position requires experience in both the business and in software development ingeneral.

4) Deliverables:As part of the software development and testing processes, it is necessary to definedeliverables, such as requirements, a testing plan, and testing cases. These will guarantee that testers caneffectively follow-up throughout the project from the software quality perspective.

5) Tool Usage:Both the use of tools for tracking and managing defects, as well as the creation of test cases and

execution, are essential for increasing the maturity of the testing & QA process. The process may begin without

tools, but they are a requisite for increasing execution maturity.

6) Metrics:Developing and creating metrics to track the software quality in its current state, as well as tocompare the improvement with previous versions, will help increase the value and maturity of the testingprocess (e.g. the number of components with errors in the software/the total number of components in thesoftware; or the number of errors detected in the testing phase/total number of errors detected).

7) Testing Environment:Implementation of appropriate testing environments that allow developers to reproduce

the system execution in production environments is crucial to the creation and execution of the correspondingtest cases.

8) Test Data:The testing environment required for day-to-day operation should provide or ensure availability ofthe necessary data to enable the corresponding test execution. Even if you have developed the appropriatetesting environments, developers need to access specific data required to execute the associated test cases.

9) Change Management:Like any other production environment, the testing environment should properly trackchanges in configuration, ensuring not only controlled results, but that the tests are run in environments thatclosely resemble those of the real production environment.

10) Developer Awareness:It is critical to have an awareness process that includes management commitment ateach and every business unit and for associated developers. The goal is to demonstrate that testing activitiesadd value to their daily work.


32/33

24) Explain Contract Management, Audits, Training and Document Control Revevant:

Contract Management:contract management process saves time and adds value to each step ofthe contract's lifecycle.Contract management or contract administration is the management of contractsmade with customers, vendors, partners, or employees.

1. Request: It all begins here, where users initiate contracts and find pertinent documents from within

familiar applications.2. Authoring: Contract creation becomes much easier with automated contract management, wherein

users author with familiar word processing tools, as well as standardized language that can be

included dynamically depending on the type of agreement.

3. Negotiation: The ability to compare redlined versions of contracts in various formats side-by-side, and

quickly note any discrepancies, reduces negotiation time by half when contract processes are

automated and streamlined.

4. Approval: In the stage that causes the most bottlenecks in contract processes, automated contract

management allows users to preemptively strike by tailoring approval workflows, including parallel and

serial approvals, and keep business clipping along at a rapid pace.

5. Execution: Automated contract execution allows users to control and shorten the signature process

with tools such as eSignature and fax support, which associates faxed documents with their proper

electronic file via barcode.

6. Obligations management: This stage ensures that deliverables are being met and that value isnt

leaking from contracts. Users maximize contract value with fulfillment tracking, automated alerts linked

to expirations, renewals, and key events, post-execution workflows, a

Documents

Software Engineering for MBA 3rd Semester Bnagalore University