Soft Engg Assign 1

7/28/2019 Soft Engg Assign 1

1/17


2/17

Simple: lowcomplexity

Stabilityunder changingrequirements

Q.2 Describe s/w process and project management?

Ans.2

Software project management is the art and science of planning and leading software projects. It is asub-discipline ofproject managementin whichsoftwareprojects are planned, implemented, monitoredand controlled.

Project management is the discipline of planning, organizing, motivating, and controlling resources toachieve specific goals. Aprojectis a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals andobjectives, typically to bring about beneficial change or added value. The temporary nature of projectsstands in contrast withbusiness as usual (or operations), which are repetitive, permanent, or semi-permanent functional activities to produce products or services. In practice, the management of these twosystems is often quite different, and as such requires the development of distinct technical skills and

management strategies.

A software development process, also known as a software development life-cycle (SDLC), is astructure imposed on thedevelopment of a software product. Similar terms include software lifecycle and software process. It is often considered a subset ofsystems development life cycle. There areseveralmodelsfor such processes, each describing approaches to a variety oftasks or activitiesthat takeplace during the process. Some people consider a life-cycle model a more general term and a softwaredevelopment process a more specific term. For example, there are many specific software developmentprocesses that 'fit' the spiral life-cycle model.ISO/IEC 12207is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing andmaintaining software.

Asoftware development processis concerned primarily with the production aspect ofsoftware

development, as opposed to the technical aspect, such assoftware tools. These processes exist primarily

for supporting the management of software development, and are generally skewed toward addressing

business concerns. Many software development processes can be run in a similar way to general project

management processes. Examples are:

Risk managementis the process of measuring orassessing riskand then developing strategies to

manage the risk. In general, the strategies employed include transferring the risk to another party,

avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the

consequences of a particular risk. Risk management in software project management begins with

thebusiness casefor starting the project, which includes acost-benefit analysisas well as a list of

fallback options for project failure, called acontingency plan.

A subset of risk management that is gaining more and more attention isOpportunity

Management, which means the same thing, except that the potential risk outcome will have a

positive, rather than a negative impact. Though theoretically handled in the same way, using the

term "opportunity" rather than the somewhat negative term "risk" helps to keep a team focused
https://en.wikipedia.org/wiki/Complexity_(disambiguation)https://en.wikipedia.org/wiki/Complexity_(disambiguation)https://en.wikipedia.org/wiki/Complexity_(disambiguation)https://en.wikipedia.org/wiki/Stability_Modelhttps://en.wikipedia.org/wiki/Stability_Modelhttps://en.wikipedia.org/wiki/Requirementshttps://en.wikipedia.org/wiki/Requirementshttps://en.wikipedia.org/wiki/Requirementshttp://en.wikipedia.org/wiki/Project_managementhttp://en.wikipedia.org/wiki/Project_managementhttp://en.wikipedia.org/wiki/Project_managementhttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Business_operationshttp://en.wikipedia.org/wiki/Business_operationshttp://en.wikipedia.org/wiki/Business_operationshttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Systems_Development_Life_Cyclehttp://en.wikipedia.org/wiki/Systems_Development_Life_Cyclehttp://en.wikipedia.org/wiki/Systems_Development_Life_Cyclehttp://en.wikipedia.org/wiki/Software_development_process#Software_development_modelshttp://en.wikipedia.org/wiki/Software_development_process#Software_development_modelshttp://en.wikipedia.org/wiki/Software_development_process#Software_development_modelshttp://en.wikipedia.org/wiki/Phases_of_the_software_development_cyclehttp://en.wikipedia.org/wiki/Phases_of_the_software_development_cyclehttp://en.wikipedia.org/wiki/Phases_of_the_software_development_cyclehttp://en.wikipedia.org/wiki/ISO/IEC_12207http://en.wikipedia.org/wiki/ISO/IEC_12207http://en.wikipedia.org/wiki/ISO/IEC_12207http://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_toolshttp://en.wikipedia.org/wiki/Software_toolshttp://en.wikipedia.org/wiki/Software_toolshttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Risk_assessmenthttp://en.wikipedia.org/wiki/Risk_assessmenthttp://en.wikipedia.org/wiki/Risk_assessmenthttp://en.wikipedia.org/wiki/Business_casehttp://en.wikipedia.org/wiki/Business_casehttp://en.wikipedia.org/wiki/Business_casehttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Contingency_planhttp://en.wikipedia.org/wiki/Contingency_planhttp://en.wikipedia.org/wiki/Contingency_planhttp://en.wikipedia.org/wiki/Opportunity_Managementhttp://en.wikipedia.org/wiki/Opportunity_Managementhttp://en.wikipedia.org/wiki/Opportunity_Managementhttp://en.wikipedia.org/wiki/Opportunity_Managementhttp://en.wikipedia.org/wiki/Opportunity_Managementhttp://en.wikipedia.org/wiki/Opportunity_Managementhttp://en.wikipedia.org/wiki/Contingency_planhttp://en.wikipedia.org/wiki/Cost-benefit_analysishttp://en.wikipedia.org/wiki/Business_casehttp://en.wikipedia.org/wiki/Risk_assessmenthttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Software_toolshttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/ISO/IEC_12207http://en.wikipedia.org/wiki/Phases_of_the_software_development_cyclehttp://en.wikipedia.org/wiki/Software_development_process#Software_development_modelshttp://en.wikipedia.org/wiki/Systems_Development_Life_Cyclehttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Business_operationshttp://en.wikipedia.org/wiki/Projecthttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Project_managementhttps://en.wikipedia.org/wiki/Requirementshttps://en.wikipedia.org/wiki/Stability_Modelhttps://en.wikipedia.org/wiki/Complexity_(disambiguation)


3/17

on possible positive outcomes of any givenrisk registerin their projects, such as spin-off

projects, windfalls, and free extra resources.

Requirements managementis the process of identifying,eliciting, documenting, analyzing,tracing,

prioritizing and agreeing on requirements and then controlling change and communicating to relevant

stakeholders. New or alteredcomputer system[1]

Requirements management, which

includesRequirements analysis, is an important part of thesoftware engineeringprocess; whereby

business analysts orsoftware developersidentify the needs or requirements of a client; having

identified these requirements they are then in a position to design a solution.

Change managementis the process of identifying, documenting, analyzing, prioritizing and agreeing

on changes toscope (project management)and then controlling changes and communicating to

relevant stakeholders.Change impact analysisof new or altered scope, which

includesRequirements analysisat the change level, is an important part of the software

engineeringprocess; whereby business analysts orsoftware developersidentify the altered needs or

requirements of a client; having identified these requirements they are then in a position to re-design

or modify a solution. Theoretically, each change can impact the timeline and budget of a software

project, and therefore by definition must includerisk-benefit analysisbefore approval.

Software configuration managementis the process of identifying, and documenting the scope itself,

which is the software product underway, including all sub-products and changes and enabling

communication of these to relevant stakeholders. In general, the processes employed include version

control,naming convention (programming), and software archival agreements.

Release managementis the process of identifying, documenting, prioritizing and agreeing on

releases of software and then controlling the release schedule and communicating to relevant

stakeholders. Most software projects have access to three software environments to which software

can be released; Development, Test, and Production. In very large projects, where distributed teams

need to integrate their work before releasing to users, there will often be more environments for

testing, calledunit testing,system testing, orintegration testing, before release toUser acceptance

testing(UAT).

A subset of release management that is gaining more and more attention is Data Management,

as obviously the users can only test based on data that they know, and "real" data is only in the

software environment called "production". In order to test their work, programmers must therefore

also often create "dummy data" or "data stubs". Traditionally, older versions of a production

system were once used for this purpose, but as companies rely more and more on outside

contributors for software development, company data may not be released to development

teams. In complex environments, datasets may be created that are then migrated across test

environments according to a test release schedule, much like the overall software release

schedule.

Q.3 What do you understand by Requirement Elicitation?
http://en.wikipedia.org/wiki/Risk_registerhttp://en.wikipedia.org/wiki/Risk_registerhttp://en.wikipedia.org/wiki/Risk_registerhttp://en.wikipedia.org/wiki/Requirements_managementhttp://en.wikipedia.org/wiki/Requirements_managementhttp://en.wikipedia.org/wiki/Requirements_elicitationhttp://en.wikipedia.org/wiki/Requirements_elicitationhttp://en.wikipedia.org/wiki/Requirements_elicitationhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Change_managementhttp://en.wikipedia.org/wiki/Change_managementhttp://en.wikipedia.org/wiki/Scope_(project_management)http://en.wikipedia.org/wiki/Scope_(project_management)http://en.wikipedia.org/wiki/Scope_(project_management)http://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Risk-benefit_analysishttp://en.wikipedia.org/wiki/Risk-benefit_analysishttp://en.wikipedia.org/wiki/Risk-benefit_analysishttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Naming_convention_(programming)http://en.wikipedia.org/wiki/Naming_convention_(programming)http://en.wikipedia.org/wiki/Naming_convention_(programming)http://en.wikipedia.org/wiki/Release_managementhttp://en.wikipedia.org/wiki/Release_managementhttp://en.wikipedia.org/wiki/Unit_testinghttp://en.wikipedia.org/wiki/Unit_testinghttp://en.wikipedia.org/wiki/Unit_testinghttp://en.wikipedia.org/wiki/System_testinghttp://en.wikipedia.org/wiki/System_testinghttp://en.wikipedia.org/wiki/System_testinghttp://en.wikipedia.org/wiki/Integration_testinghttp://en.wikipedia.org/wiki/Integration_testinghttp://en.wikipedia.org/wiki/Integration_testinghttp://en.wikipedia.org/wiki/User_acceptance_testinghttp://en.wikipedia.org/wiki/User_acceptance_testinghttp://en.wikipedia.org/wiki/User_acceptance_testinghttp://en.wikipedia.org/wiki/User_acceptance_testinghttp://en.wikipedia.org/wiki/Data_Managementhttp://en.wikipedia.org/wiki/Data_Managementhttp://en.wikipedia.org/wiki/Data_Managementhttp://en.wikipedia.org/wiki/Data_Managementhttp://en.wikipedia.org/wiki/User_acceptance_testinghttp://en.wikipedia.org/wiki/User_acceptance_testinghttp://en.wikipedia.org/wiki/Integration_testinghttp://en.wikipedia.org/wiki/System_testinghttp://en.wikipedia.org/wiki/Unit_testinghttp://en.wikipedia.org/wiki/Release_managementhttp://en.wikipedia.org/wiki/Naming_convention_(programming)http://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Version_controlhttp://en.wikipedia.org/wiki/Software_configuration_managementhttp://en.wikipedia.org/wiki/Risk-benefit_analysishttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Scope_(project_management)http://en.wikipedia.org/wiki/Change_managementhttp://en.wikipedia.org/wiki/Software_developershttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Requirements_analysishttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Computer_systemhttp://en.wikipedia.org/wiki/Requirements_traceabilityhttp://en.wikipedia.org/wiki/Requirements_elicitationhttp://en.wikipedia.org/wiki/Requirements_managementhttp://en.wikipedia.org/wiki/Risk_register


4/17

Ans.3

Inrequirements engineering,requirements elicitation is the practice of collecting the requirements of a

system from users, customers and other stakeholders. The practice is also sometimes referred to

as requirements gathering.

The term elicitation is used in books and research to raise the fact that good requirements can not just be

collected from the customer, as would be indicated by the name requirements gathering. Requirements

elicitation is non-trivial because you can never be sure you get all requirements from the user and

customer by just asking them what the system should do. Requirements elicitation practices include

interviews, questionnaires, user observation, workshops, brain storming,use cases, role playing

andprototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation

process. Requirements elicitation is a part of the requirements engineering process, usually followed by

analysis and specification of the requirements.

Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an

important first meeting could be between software engineers and customers where they discuss theirperspective of the requirements.

Q.4 What is role of use case diagrams in UML?

Ans.4

Insoftwareandsystems engineering, a use case is a list of steps, typically defining interactions between

a role (known inUMLas an "actor") and a system, to achieve a goal. The actor can be a human or an

external system.

In systems engineering, use cases are used at a higher level than within software engineering, often

representing missions orstakeholdergoals. The detailed requirements may then be captured in SysMLor

as contractual statements.

A use case diagram at its simplest is a representation of a user's interaction with the system anddepicting the specifications of ause case. A use case diagram can portray the different types of users ofa system and the various ways that they interact with the system. This type of diagram is typically used inconjunction with the textualuse caseand will often be accompanied by other types of diagrams as well

Application

With regards to use case diagrams, that is exactly what they are meant to do. While ause caseitself

might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level

view of the system. It has been said before that "Use case diagrams are the blueprints for your

system".[1]

They provide the simplified and graphical representation of what the system must actually do.
http://en.wikipedia.org/wiki/Requirements_engineeringhttp://en.wikipedia.org/wiki/Requirements_engineeringhttp://en.wikipedia.org/wiki/Requirements_engineeringhttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Software_prototypinghttp://en.wikipedia.org/wiki/Software_prototypinghttp://en.wikipedia.org/wiki/Software_prototypinghttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Systems_engineeringhttp://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/Actor_(UML)http://en.wikipedia.org/wiki/Actor_(UML)http://en.wikipedia.org/wiki/Actor_(UML)http://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/SysMLhttp://en.wikipedia.org/wiki/SysMLhttp://en.wikipedia.org/wiki/SysMLhttp://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/Use_Casehttp://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/Use_Case_Diagram#cite_note-1http://en.wikipedia.org/wiki/Use_Case_Diagram#cite_note-1http://en.wikipedia.org/wiki/Use_Case_Diagram#cite_note-1http://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/Use_Casehttp://en.wikipedia.org/wiki/SysMLhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Actor_(UML)http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_prototypinghttp://en.wikipedia.org/wiki/Use_caseshttp://en.wikipedia.org/wiki/Requirements_engineering


5/17

Due to their simplistic nature, use case diagrams can be a good communication tool forstakeholders. The

drawings attempt to mimic the real world and provide a view for thestakeholderto understand how the

system is going to be designed. Siau and Lee conducted research to determine if there was a valid

situation for use case diagrams at all or if they were unnecessary. What was found was that the use case

diagrams conveyed the intent of the system in a more simplified manner tostakeholdersand that they

were "interpreted more completely than class diagrams". The purpose of the use case diagrams is simplyto provide the high level view of the system and convey the requirements in layman's terms for

thestakeholders. Additional diagrams and documentation can be used to provide a complete functional

and technical view of the system.

Q.5 What is sequence diagram?

Ans.5
http://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholderhttp://en.wikipedia.org/wiki/Project_stakeholder


6/17

A sequence diagram is a kind ofinteraction diagramthat shows how processes operate with one

another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows

object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario

and the sequence of messages exchanged between the objects needed to carry out the functionality of

the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View

of the system under development. Sequence diagrams are sometimes called event diagrams, eventscenarios, andtiming diagrams.

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live

simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which

they occur. This allows the specification of simple runtime scenarios in a graphical manner.

Diagram building blocks

If the lifeline is that of an object, it demonstrates a role. Note that leaving the instance name blank can

represent anonymous and unnamed instances.

In order to display interaction, messages are used. These are horizontal arrowswith the message name

written above them. Solid arrows with full heads are synchronous calls, solid arrows with stick heads are

asynchronous calls and dashed arrows with stick heads are return messages. This definition is true as

ofUML2, considerably different from UML 1.x. If a caller sends a synchronous message, it must wait until

the message is done, such as invoking a subroutine. If a caller sends an asynchronous message, it can

continue processing and doesnt have to wait for a response. You see asynchronous calls in

multithreaded applications and in message-oriented middleware. Activation boxes, ormethod-call boxes,

are opaque rectangles drawn on top of lifelines to represent that processes are being performed in

response to the message (ExecutionSpecifications in UML).

Objects calling methods on themselves use messages and add new activation boxes on top of any others

to indicate a further level ofprocessing.

When an object isdestroyed(removed frommemory), an X is drawn on top of the lifeline, and the dashed

line ceases to be drawn below it (this is not the case in the first example though). It should be the result of

a message, either from the object itself, or another.

A message sent from outside the diagram can be represented by a message originating from a filled-in

circle (found message in UML) or from a border of the sequence diagram (gate in UML).

UML 2 has introduced significant improvements to the capabilities of sequence diagrams. Most of these

improvements are based on the idea of interaction fragments which represent smaller pieces of an

enclosing interaction. Multiple interaction fragments are combined to create a variety ofcombined

fragments, which are then used to model interactions that include parallelism, conditional branches,

optional interactions
http://en.wikipedia.org/wiki/Interaction_diagramhttp://en.wikipedia.org/wiki/Interaction_diagramhttp://en.wikipedia.org/wiki/Interaction_diagramhttp://en.wikipedia.org/wiki/Message_Sequence_Charthttp://en.wikipedia.org/wiki/Message_Sequence_Charthttp://en.wikipedia.org/wiki/Message_Sequence_Charthttp://en.wikipedia.org/wiki/Timing_diagram_(Unified_Modeling_Language)http://en.wikipedia.org/wiki/Timing_diagram_(Unified_Modeling_Language)http://en.wikipedia.org/wiki/Timing_diagram_(Unified_Modeling_Language)http://en.wikipedia.org/wiki/Arrow_(symbol)http://en.wikipedia.org/wiki/Arrow_(symbol)http://en.wikipedia.org/wiki/Arrow_(symbol)http://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/Method_(computer_science)http://en.wikipedia.org/wiki/Method_(computer_science)http://en.wikipedia.org/wiki/Method_(computer_science)http://en.wikipedia.org/wiki/Process_(computing)http://en.wikipedia.org/wiki/Process_(computing)http://en.wikipedia.org/wiki/Process_(computing)http://en.wikipedia.org/wiki/Object_lifetimehttp://en.wikipedia.org/wiki/Object_lifetimehttp://en.wikipedia.org/wiki/Object_lifetimehttp://en.wikipedia.org/wiki/Computer_storagehttp://en.wikipedia.org/wiki/Computer_storagehttp://en.wikipedia.org/wiki/Computer_storagehttp://en.wikipedia.org/wiki/Computer_storagehttp://en.wikipedia.org/wiki/Object_lifetimehttp://en.wikipedia.org/wiki/Process_(computing)http://en.wikipedia.org/wiki/Method_(computer_science)http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Arrow_(symbol)http://en.wikipedia.org/wiki/Timing_diagram_(Unified_Modeling_Language)http://en.wikipedia.org/wiki/Message_Sequence_Charthttp://en.wikipedia.org/wiki/Interaction_diagram


7/17

Q.6 What do you understand by terms software reliability?

Ans.6

Software Reliability is the probability of failure-free software operation for a specified period of time in a

specified environment. Software Reliability is also an important factor affecting system reliability. It differs

from hardware reliability in that it reflects the design perfection, rather than manufacturing perfection. The

high complexity of software is the major contributing factor of Software Reliability problems. Software

Reliability is not a function of time - although researchers have come up with models relating the two. The

modeling technique for Software Reliability is reaching its prosperity, but before using the technique, we

must carefully select the appropriate model that can best suit our case. Measurement in software is still in

its infancy. No good quantitative methods have been developed to represent Software Reliability without

excessive limitations. Various approaches can be used to improve the reliability of software, however, it is

hard to balance development time and budget with software reliability.

The bathtub curve for Software Reliability

Over time, hardware exhibits the failure characteristics shown in Figure 1, known as the bathtub curve.Period A, B and C stands for burn-in phase, useful life phase and end-of-life phase. A detailed discussionabout the curve can be found in the topicTraditional Reliability.
http://www.ece.cmu.edu/F:/usr/jpan/traditional_reliability/index.html#Component%20Reliability%20Lifetime%20Modelhttp://www.ece.cmu.edu/F:/usr/jpan/traditional_reliability/index.html#Component%20Reliability%20Lifetime%20Modelhttp://www.ece.cmu.edu/F:/usr/jpan/traditional_reliability/index.html#Component%20Reliability%20Lifetime%20Modelhttp://www.ece.cmu.edu/F:/usr/jpan/traditional_reliability/index.html#Component%20Reliability%20Lifetime%20Model


8/17

Figure 1. Bathtub curve for hardware reliability

Software reliability, however, does not show the same characteristics similar as hardware. A possiblecurve is shown in Figure 2 if we projected software reliability on the same axes.There are two majordifferences between hardware and software curves. One difference is that in the last phase, softwaredoes not have an increasing failure rate as hardware does. In this phase, software is approachingobsolescence; there are no motivation for any upgrades or changes to the software. Therefore, the failurerate will not change. The second difference is that in the useful-life phase, software will experience adrastic increase in failure rate each time an upgrade is made. The failure rate levels off gradually, partly

because of the defects found and fixed after the upgrades.

Figure 2. Revised bathtub curve for software reliability


9/17

The upgrades in Figure 2 imply feature upgrades, not upgrades for reliability. For feature upgrades, thecomplexity of software is likely to be increased, since the functionality of software is enhanced. Even bugfixes may be a reason for more software failures, if the bug fix induces other defects into software. Forreliability upgrades, it is possible to incur a drop in software failure rate, if the goal of the upgrade isenhancing software reliability, such as a redesign or reimplementation of some modules using betterengineering approaches, such as clean-room method.

Q.7 What is component based s/w engineering?

Ans.7

Component-based software engineering (CBSE) (also known as component-based development

(CBD)) is a branch ofsoftware engineeringthat emphasizes theseparation of concernsin respect of the

wide-ranging functionality available throughout a givensoftware system. It is a reuse-based approach to

defining, implementing and composing loosely coupled independent components into systems. This

practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the

long-term for the software itself and for organizations that sponsor such software.

Software engineers regard components as part of the starting platform forservice-orientation.

Components play this role, for example, inweb services, and more recently, inservice-oriented

architectures(SOA), whereby a component is converted by the web service into a service and

subsequently inherits further characteristics beyond that of an ordinary component.

Components can produce or consume events and can be used forevent-driven architectures(EDA)

A simple example of two components expressed inUML2.0. The checkout component, responsible for

facilitating the customer's order,requires the card processing component to charge the customer's

credit/debit card (functionality that the latterprovides).
http://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Separation_of_concernshttp://en.wikipedia.org/wiki/Separation_of_concernshttp://en.wikipedia.org/wiki/Separation_of_concernshttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Service-orientationhttp://en.wikipedia.org/wiki/Service-orientationhttp://en.wikipedia.org/wiki/Service-orientationhttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Service-oriented_architecturehttp://en.wikipedia.org/wiki/Service-oriented_architecturehttp://en.wikipedia.org/wiki/Service-oriented_architecturehttp://en.wikipedia.org/wiki/Service-oriented_architecturehttp://en.wikipedia.org/wiki/Event-driven_architecturehttp://en.wikipedia.org/wiki/Event-driven_architecturehttp://en.wikipedia.org/wiki/Event-driven_architecturehttp://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/File:Component-based_Software_Engineering_(CBSE)_-_example_1.svghttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Event-driven_architecturehttp://en.wikipedia.org/wiki/Service-oriented_architecturehttp://en.wikipedia.org/wiki/Service-oriented_architecturehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Service-orientationhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Separation_of_concernshttp://en.wikipedia.org/wiki/Software_engineering


10/17

Definition and characteristics of components

An individual software component is asoftware package, aweb service, aweb resource, or

amodulethat encapsulates a set of related functions (or data).

All system processes are placed into separate components so that all of the data and functions inside

each component are semantically related (just as with the contents of classes). Because of this principle,

it is often said that components are modularand cohesive.

With regard to system-wide co-ordination, components communicate with each other via interfaces. When

a component offers services to the rest of the system, it adopts aprovidedinterface that specifies the

services that other components can utilize, and how they can do so. This interface can be seen as a

signature of the component - the client does not need to know about the inner workings of the component

(implementation) in order to make use of it. This principle results in components referred to

asencapsulated. TheUMLillustrations within this article represent provided interfaces by a lollipop-

symbol attached to the outer edge of the component.

However, when a component needs to use another component in order to function, it adopts

a usedinterface that specifies the services that it needs. In the UML illustrations in this article, used

interfaces are represented by an open socket symbol attached to the outer edge of the component.

A simple example of several software components - pictured within a hypothetical holiday-reservation

system represented inUML2.0.

Another important attribute of components is that they aresubstitutable, so that a component can replace

another (at design time or run-time), if the successor component meets the requirements of the initial

component (expressed via the interfaces). Consequently, components can be replaced with either an

updated version or an alternative without breaking the system in which the component operates.

As a general rule of thumb for engineers substituting components, component B can immediately replace

component A, if component B provides at least what component A provided and uses no more than what

component A used.
http://en.wikipedia.org/wiki/Package_(package_management_system)http://en.wikipedia.org/wiki/Package_(package_management_system)http://en.wikipedia.org/wiki/Package_(package_management_system)http://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Web_resourcehttp://en.wikipedia.org/wiki/Web_resourcehttp://en.wikipedia.org/wiki/Web_resourcehttp://en.wikipedia.org/wiki/Modular_programminghttp://en.wikipedia.org/wiki/Modular_programminghttp://en.wikipedia.org/wiki/Modular_programminghttp://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)http://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/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/File:Component-based-Software-Engineering-example2.gifhttp://en.wikipedia.org/wiki/File:Component-based-Software-Engineering-example2.gifhttp://en.wikipedia.org/wiki/File:Component-based-Software-Engineering-example2.gifhttp://en.wikipedia.org/wiki/File:Component-based-Software-Engineering-example2.gifhttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)http://en.wikipedia.org/wiki/Modular_programminghttp://en.wikipedia.org/wiki/Web_resourcehttp://en.wikipedia.org/wiki/Web_servicehttp://en.wikipedia.org/wiki/Package_(package_management_system)


11/17

Software components often take the form ofobjects(notclasses) or collections of objects (fromobject-

oriented programming), in some binary or textual form, adhering to someinterface description

language(IDL) so that the component may exist autonomously from other components in acomputer.

When a component is to be accessed or shared across execution contexts or network links, techniques

such asserializationormarshallingare often employed to deliver the component to its destination.

Reusabilityis an important characteristic of a high-quality software component. Programmers should

design and implement software components in such a way that many different programs can reuse them.

Furthermore,component-based usability testingshould be considered when software components

directly interact with users.

It takes significant effort and awareness to write a software component that is effectively reusable. The

component needs to be:

fully documented

thoroughly tested

robust - with comprehensive input-validity checking

able to pass back appropriateerror messagesor return codes

designed with an awareness that it willbe put to unforeseen uses

In the 1960s, programmers built scientificsubroutinelibraries that were reusable in a broad array of

engineering and scientific applications. Though these subroutine libraries reused well-

definedalgorithmsin an effective manner, they had a limited domain of application. Commercial sites

routinely created application programs from reusable modules written inAssembler,COBOL,PL/1and

othersecond-andthird-generation languagesusing bothsystemand user application libraries.

As of 2010, modern reusable components encapsulate both data structures and the algorithms that are

applied to the data structures. It[clarification needed]

builds on prior theories ofsoftware objects,software

architectures,software frameworksandsoftware design patterns, and the extensive theory ofobject-

oriented programmingand theobject oriented designof all these. It claims that software components, like

the idea of hardwarecomponents, used for example in telecommunications, can ultimately be made

interchangeable and reliable. On the other hand, it is argued that it is a mistake to focus on independent

components rather than the framework (without which they would not exist).

Q.8 Describe the spiral model?

Ans.8

The spiral model is asoftware development processcombining elements of

bothdesignandprototyping-in-stages, in an effort to combine advantages oftop-down and bottom-

upconcepts. Also known as the spiral lifecycle model (or spiral development), it is a systems

development method (SDM) used ininformation technology(IT). This model of development combines

the features of the prototyping and thewaterfall model. The spiral model is intended for large, expensive

and complicated projects.
http://en.wikipedia.org/wiki/Object_(computing)http://en.wikipedia.org/wiki/Object_(computing)http://en.wikipedia.org/wiki/Object_(computing)http://en.wikipedia.org/wiki/Class_(computer_science)http://en.wikipedia.org/wiki/Class_(computer_science)http://en.wikipedia.org/wiki/Class_(computer_science)http://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Interface_description_languagehttp://en.wikipedia.org/wiki/Interface_description_languagehttp://en.wikipedia.org/wiki/Interface_description_languagehttp://en.wikipedia.org/wiki/Interface_description_languagehttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Serializationhttp://en.wikipedia.org/wiki/Serializationhttp://en.wikipedia.org/wiki/Serializationhttp://en.wikipedia.org/wiki/Marshalling_(computer_science)http://en.wikipedia.org/wiki/Marshalling_(computer_science)http://en.wikipedia.org/wiki/Marshalling_(computer_science)http://en.wikipedia.org/wiki/Reusabilityhttp://en.wikipedia.org/wiki/Reusabilityhttp://en.wikipedia.org/wiki/Component-Based_Usability_Testinghttp://en.wikipedia.org/wiki/Component-Based_Usability_Testinghttp://en.wikipedia.org/wiki/Component-Based_Usability_Testinghttp://en.wikipedia.org/wiki/Error_messagehttp://en.wikipedia.org/wiki/Error_messagehttp://en.wikipedia.org/wiki/Error_messagehttp://en.wikipedia.org/wiki/Subroutinehttp://en.wikipedia.org/wiki/Subroutinehttp://en.wikipedia.org/wiki/Subroutinehttp://en.wikipedia.org/wiki/Algorithmshttp://en.wikipedia.org/wiki/Algorithmshttp://en.wikipedia.org/wiki/Algorithmshttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/COBOLhttp://en.wikipedia.org/wiki/COBOLhttp://en.wikipedia.org/wiki/COBOLhttp://en.wikipedia.org/wiki/PL/1http://en.wikipedia.org/wiki/PL/1http://en.wikipedia.org/wiki/PL/1http://en.wikipedia.org/wiki/Second_generation_languagehttp://en.wikipedia.org/wiki/Second_generation_languagehttp://en.wikipedia.org/wiki/Second_generation_languagehttp://en.wikipedia.org/wiki/Third_generation_languagehttp://en.wikipedia.org/wiki/Third_generation_languagehttp://en.wikipedia.org/wiki/Third_generation_languagehttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Wikipedia:Please_clarifyhttp://en.wikipedia.org/wiki/Wikipedia:Please_clarifyhttp://en.wikipedia.org/wiki/Wikipedia:Please_clarifyhttp://en.wikipedia.org/wiki/Object_(object-oriented_programming)http://en.wikipedia.org/wiki/Object_(object-oriented_programming)http://en.wikipedia.org/wiki/Object_(object-oriented_programming)http://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_frameworkhttp://en.wikipedia.org/wiki/Software_frameworkhttp://en.wikipedia.org/wiki/Software_frameworkhttp://en.wikipedia.org/wiki/Software_design_patternhttp://en.wikipedia.org/wiki/Software_design_patternhttp://en.wikipedia.org/wiki/Software_design_patternhttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object_oriented_designhttp://en.wikipedia.org/wiki/Object_oriented_designhttp://en.wikipedia.org/wiki/Object_oriented_designhttp://en.wikipedia.org/wiki/Electronic_componenthttp://en.wikipedia.org/wiki/Electronic_componenthttp://en.wikipedia.org/wiki/Electronic_componenthttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Designhttp://en.wikipedia.org/wiki/Designhttp://en.wikipedia.org/wiki/Designhttp://en.wikipedia.org/wiki/Prototypinghttp://en.wikipedia.org/wiki/Prototypinghttp://en.wikipedia.org/wiki/Prototypinghttp://en.wikipedia.org/wiki/Top-down_and_bottom-up_designhttp://en.wikipedia.org/wiki/Top-down_and_bottom-up_designhttp://en.wikipedia.org/wiki/Top-down_and_bottom-up_designhttp://en.wikipedia.org/wiki/Top-down_and_bottom-up_designhttp://en.wikipedia.org/wiki/Information_technologyhttp://en.wikipedia.org/wiki/Information_technologyhttp://en.wikipedia.org/wiki/Information_technologyhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Information_technologyhttp://en.wikipedia.org/wiki/Top-down_and_bottom-up_designhttp://en.wikipedia.org/wiki/Top-down_and_bottom-up_designhttp://en.wikipedia.org/wiki/Prototypinghttp://en.wikipedia.org/wiki/Designhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Electronic_componenthttp://en.wikipedia.org/wiki/Object_oriented_designhttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Software_design_patternhttp://en.wikipedia.org/wiki/Software_frameworkhttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Object_(object-oriented_programming)http://en.wikipedia.org/wiki/Wikipedia:Please_clarifyhttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Third_generation_languagehttp://en.wikipedia.org/wiki/Second_generation_languagehttp://en.wikipedia.org/wiki/PL/1http://en.wikipedia.org/wiki/COBOLhttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/Algorithmshttp://en.wikipedia.org/wiki/Subroutinehttp://en.wikipedia.org/wiki/Error_messagehttp://en.wikipedia.org/wiki/Component-Based_Usability_Testinghttp://en.wikipedia.org/wiki/Reusabilityhttp://en.wikipedia.org/wiki/Marshalling_(computer_science)http://en.wikipedia.org/wiki/Serializationhttp://en.wikipedia.org/wiki/Computerhttp://en.wikipedia.org/wiki/Interface_description_languagehttp://en.wikipedia.org/wiki/Interface_description_languagehttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Object-oriented_programminghttp://en.wikipedia.org/wiki/Class_(computer_science)http://en.wikipedia.org/wiki/Object_(computing)


12/17

The spiral model combines the idea ofiterative development(prototyping) with the systematic, controlled

aspects of thewaterfall model. It allows for incremental releases of the product, or incremental refinement

through each time around the spiral. The spiral model also explicitly includesrisk

managementwithinsoftware development. Identifying major risks, both technical and managerial, and

determining how to lessen the risk helps keep thesoftware development processunder control.

The spiral model is based on continuous refinement of key products for requirements definition

andanalysis,systemandsoftware design, andimplementation(the code). At each iteration around the

cycle, the products are extensions of an earlier product. This model uses many of the same phases as

the waterfall model, in essentially the same order, separated by planning, risk assessment, and the

building of prototypes and simulations.

Documents are produced when they are required, and the content reflects the information necessary at

that point in the process. All documents will not be created at the beginning of the process, nor all at the

end (hopefully). Like the product they define, the documents are works in progress. The idea is to have a

continuous stream of products produced and available for user review.

The spiral lifecycle model allows for elements of the product to be added in when they become available

or known. This assures that there is no conflict with previous requirements and design. This method is

consistent with approaches that have multiple software builds and releases and allows for making an
http://en.wikipedia.org/wiki/Iterative_developmenthttp://en.wikipedia.org/wiki/Iterative_developmenthttp://en.wikipedia.org/wiki/Iterative_developmenthttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Systems_designhttp://en.wikipedia.org/wiki/Systems_designhttp://en.wikipedia.org/wiki/Systems_designhttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Computer_programminghttp://en.wikipedia.org/wiki/Computer_programminghttp://en.wikipedia.org/wiki/Computer_programminghttp://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Systems_designhttp://en.wikipedia.org/wiki/Systems_analysishttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Risk_managementhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Iterative_development


13/17

orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early

user involvement in the system development effort. For projects with heavy user interfacing, such as user

application programs or instrument interface applications, such involvement is helpful.

Starting at the center, each turn around the spiral goes through several task regions :

Determine the objectives, alternatives, and constraints on the new iteration.

Evaluate alternatives and identify and resolve risk issues.

Develop and verify the product for this iteration.

Plan the next iteration.

Note that the requirements activity takes place in multiple sections and in multiple iterations, just as

planning and risk analysis occur in multiple places. Final design, implementation, integration, and test

occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using this method of

development, some functionality can be delivered to the user faster than the waterfall method. The spiral

method also helps manage risk and uncertainty by allowing multiple decision points and by explicitly

admitting that all of anything cannot be known before the subsequent activity starts.

Q.9 Write a short note onCOCOMO model

Ans.9

The Constructive Cost Model (COCOMO) is an algorithmicsoftware cost estimation modeldeveloped

byBarry W. Boehm. The model uses a basicregressionformula with parameters that are derived from

historical project data and current as well as future project characteristics.

COCOMO was first published in Boehm's 1981 book Software Engineering Economics[1]

as a model for

estimating effort, cost, and schedule for software projects. It drew on a study of 63 projects

atTRWAerospace where Boehm was Director of Software Research and Technology. The study

examined projects ranging in size from 2,000 to 100,000lines of code, and programming languages

ranging fromassemblytoPL/I. These projects were based on thewaterfall modelof software

development which was the prevalent software development process in 1981.

References to this model typically call it COCOMO 81. In 1995 COCOMO IIwas developed and finally

published in 2000 in the book Software Cost Estimation with COCOMO II.[2]

COCOMO II is the successor

of COCOMO 81 and is better suited for estimating modern software development projects. It provides

more support for modernsoftware development processesand an updated project database. The need

for the new model came as software development technology moved from mainframe and overnight

batch processing to desktop development, code reusability and the use of off-the-shelf software

components. This article refers to COCOMO 81.

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
http://en.wikipedia.org/wiki/Estimation_in_software_engineeringhttp://en.wikipedia.org/wiki/Estimation_in_software_engineeringhttp://en.wikipedia.org/wiki/Estimation_in_software_engineeringhttp://en.wikipedia.org/wiki/Barry_Boehmhttp://en.wikipedia.org/wiki/Barry_Boehmhttp://en.wikipedia.org/wiki/Barry_Boehmhttp://en.wikipedia.org/wiki/Regression_analysishttp://en.wikipedia.org/wiki/Regression_analysishttp://en.wikipedia.org/wiki/Regression_analysishttp://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo1-1http://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo1-1http://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo1-1http://en.wikipedia.org/wiki/TRW_Inc.http://en.wikipedia.org/wiki/TRW_Inc.http://en.wikipedia.org/wiki/TRW_Inc.http://en.wikipedia.org/wiki/Lines_of_codehttp://en.wikipedia.org/wiki/Lines_of_codehttp://en.wikipedia.org/wiki/Lines_of_codehttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/PL/Ihttp://en.wikipedia.org/wiki/PL/Ihttp://en.wikipedia.org/wiki/PL/Ihttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo2-2http://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo2-2http://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo2-2http://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo2-2http://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/PL/Ihttp://en.wikipedia.org/wiki/Assembly_languagehttp://en.wikipedia.org/wiki/Lines_of_codehttp://en.wikipedia.org/wiki/TRW_Inc.http://en.wikipedia.org/wiki/COCOMO#cite_note-cocomo1-1http://en.wikipedia.org/wiki/Regression_analysishttp://en.wikipedia.org/wiki/Barry_Boehmhttp://en.wikipedia.org/wiki/Estimation_in_software_engineering


14/17

Drivers). Intermediate COCOMO takes these Cost Drivers into account and Detailed

COCOMO additionally accounts for the influence of individual project phases.

Basic COCOMO

Basic COCOMO computes software development effort (and cost) as a function of program size.

Program size is expressed in estimated thousands of source lines of code (SLOC)

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. It is also combination of organic

and semi-detached projects.(hardware, software, operational, ...)

The basic COCOMO equations take the form

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

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

People required (P) = Effort Applied / Development Time [count]

where, KLOC is the estimated number of delivered lines (expressed in thousands ) of code

for project. 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 COCOMOs

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:-
http://en.wikipedia.org/wiki/Source_lines_of_codehttp://en.wikipedia.org/wiki/Source_lines_of_codehttp://en.wikipedia.org/wiki/Source_lines_of_codehttp://en.wikipedia.org/wiki/Man-monthhttp://en.wikipedia.org/wiki/Man-monthhttp://en.wikipedia.org/wiki/Man-monthhttp://en.wikipedia.org/wiki/Man-monthhttp://en.wikipedia.org/wiki/Source_lines_of_code


15/17

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 attributes

Analyst capability

Software engineering capability

Applications experience

Virtual machine experience

Programming language experience

Project attributes

Use of software tools

Application of software engineering methods

Required development schedule

The Intermediate Cocomo formula now takes the form:

E=ai(KLoC)(b

i)

.EAF

where E is the effort applied in person-months, KLoC is the estimated number of thousands of

delivered lines of code for the project, and EAF is the factor calculated above. The coefficient ai and

the exponent bi are given in the next table.

Software project ai bi

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20

The Development time D calculation uses E in the same way as in the Basic COCOMO.


16/17

Detailed COCOMO

Detailed COCOMO incorporates all characteristics of the intermediate version with an

assessment of the cost driver's impact on each step (analysis, design, etc.) of the software

engineering process.

The detailed model uses different effort multipliers for each cost driver attribute. These Phase

Sensitive effort multipliers are each to determine the amount of effort required to complete each

phase.

In detailed COCOMO, the effort is calculated as function of program size and a set of cost

drivers given according to each phase of software life cycle.

A Detailed project schedule is never static.

The five phases of detailed COCOMO are:-

plan and requirement.

system design. detailed design.

module code and test.

integration and test.

Q.10 What are the characteristics of s/w process?Ans.10

Effectiveness. -: An effective process must help us produce the right product. It doesn't matter howelegant and well-written the software, nor how quickly we have produced it. If it isn't what thecustomer wanted, or required, it's no good. The process should therefore help us determine what the

customer needs, produce what the customer needs, and, crucially, verify that what we have producedis what the customer needs

Maintainability. -:However good the programmer, things will still go wrong with the software.Requirements often change between versions. In any case, we may want to reuse elements of thesoftware in other products. None of this is made any easier if, when a problem is discovered,everybody stands around scratching their heads saying "Oh dear, the person that wrote this left thecompany last week" or worse, "Does anybody know who wrote this code?" One of the goals of a goodprocess is to expose the designers' and programmers' thought processes in such a way that theirintention is clear. Then we can quickly and easily find and remedy faults or work out where to makechanges

Predictability. -: Any new product development needs to be planned, and those plans are used as the

basis for allocating resources: both time and people. It is important to predict accurately how long itwill take to develop the product. That means estimating accurately how long it will take to produceeach part of it - including the software. A good process will help us do this. The process helps lay outthe steps of development. Furthermore, consistency of process allows us to learn from the designs ofother projects

Repeatability. - :If a process is discovered to work, it should be replicated in future projects. Ad-hocprocesses are rarely replicable unless the same team is working on the new project. Even with thesame team, it is difficult to keep things exactly the same. A closely related issue, is that of process re-use. It is a huge waste and overhead for each project to produce a process from scratch. It is much


17/17

faster and easier to adapt an existing process

Quality. -:Quality in this case may be defined as the product's fitness for its purpose. One goal of adefined process is to enable software engineers to ensure a high quality product. The process shouldprovide a clear link between a customer's desires and a developer's product

Improvement. -:No one would expect their process to reach perfection and need no furtherimprovement itself. Even if we were as good as we could be now, both development environmentsand requested products are changing so quickly that our processes will always be running to catchup. A goal of our defined process must then be to identify and prototype possibilities for improvementin the process itself.

Tracking -: A defined process should allow the management, developers, and customer to follow thestatus of a project. Tracking is the flip side of predictability. It keeps track of how good our predictionsare, and hence how to improve them