Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1


Ratings: (0)|Views: 2,483|Likes:
Published by Anshuman Kar

More info:

Published by: Anshuman Kar on Jul 19, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Q1. Write a note on myths of Software.
Myth is defined as "widely held but false notation" by the oxford dictionary, so assign other fields software arena also hassome myths to demystify. Pressman
insists “Software
myths- beliefs about software and the process used to build it- can betraced to earliest days of computing. Myths have anumber of attributes that have made them insidious." So software myths prevail but though they do are not clearly visible they have the potential to harm all the parties involved in the softwaredevelopment process mainly the developer team. Tom
DeMarco expresses “In the absence of meaningful standards, a
newindustry like software comes to depend instead on folklore." The given statement points out that the software industrycaught pace just some decades back so it has not matured to formidable level and there are no strict standards in softwaredevelopment. There does not exist one best method of software development that ultimately equates to the ubiquitoussoftware myths. Primarily, there are three types of software myths, all the three are stated below: 1.ManagementMyth2.CustomerMyth3.Practitioner/Developer Myth before defining the above three myths one by one lets scrutinize whythese myths occur on the first place. The picture below tries to clarify the complexity of the problem of softwaredevelopment requirement analysis mainly between the developer team and the clients.
Q2. Explain Version Control & Change Control.
Version Control
& Change Control.
 A version control system (or revision control system) is a combination of technologies and practices fort racking andcontrolling changes to a project's files, in particular to source code, documentation, andweb pages. If you have never used version control before, the first thing you should do is go find someone who has, and get them to join your project.These days, everyone will expect at least
your project‟s
source code to be under version control, and probably will nottake the project seriously if 
it doesn‟t
use version control with at least minimal competence. The reason version control isso universal is that it helps with virtually every aspect of running a project: inter-developer communications, releasemanagement, bug management, code stability and experimental development efforts, and attribution and authorization of changes by particular developers.The version control system provides a central coordinating force among all of these areas. The core of versioncontrol is change management: identifying each discrete change made to theproject's files, annotating each change withmetadata like the change's date and author, and then replaying these facts to whoever asks, in whatever way they ask. It is acommunications mechanism where a change is the basic unit of information. This section does not discuss all aspects of using a version control system. It's so all-encompassing that it must be addressed topically throughout the book. Here, wewill concentrate on choosing and setting upa version control system in a way that will foster cooperative developmentdown the road.
Q3. Discuss the SCM Process.
In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in thesoftware. Configuration management practices include revision control and the establishment of baselines.SCM concernsitself with answering the question "Somebody did something, how can one reproduce it?"Often the problem involves notreproducing "it" identically, but with controlled, incremental changes.Answering the question thus becomes a matter of comparing different results and of analyzing their differences.Traditional configuration management typically focused on controlled creation of relatively simple products. Now,implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in thecontext of the complex system being developed. According to another simple definition: Software ConfigurationManagement is how you control the evolution of software project.
The goals of SCM
Configuration identification - Identifying configurations, configuration items and baselines.
Configuration control - Implementing a controlled change process. This is usually achieved by setting upa changecontrol board whose primary function is to approve or reject all change requests that are sentagainst any baseline.
Configuration status accounting - Recording and reporting all the necessary information on the status of thedevelopment process.
Configuration auditing - Ensuring that configurations contain all their intended parts and are sound withrespect totheir specifying documents, including requirements, architectural specifications and usermanuals.
Build management - Managing the process and tools used for builds.
Process management - Ensuring adherence to the organization's development process.
Environment management - Managing the software and hardware that host the system.
Teamwork - Facilitate team interactions related to the process.
Defect tracking - Making sure every defect has traceability back to the source.
Q4. Explain
i. Software doesn’t Wear 
Out. ii. Software is engineered & not manufactured.
Software doesn‟t Wear Out.
The hardware can wear out whereas software can't. In case of hardware we have a "bathtub “like curve, which is a curve
that lies in between failure-rate and time. In this curve, in the starting time there is relatively high failure rate. But, after some period of time, defects get corrected and failure-rate drops to a steady-state for some time period. But, the failure-rateagain rises due to the effects of rain, dust, temperature extreme and many other environment effects. The hardware beginsto wear out.But, the software is not responsible to the failure rate of hardware. The failure rate of software can be understood by the "idealized curve". In this type of curve the failure rate in the initial state is very high. But, the errors in the softwareget corrected and the curve flattens. However, the implication is clear that the software can "deteriorate" it does not "wear 
out”. This can be explained by the ac
tual curve. As soon as that error gets corrected the curveencounters another spike thatmeans another error in the software. After some time the steady state of the software don't remains steady and the failurerate begins to rise. If hardware getsfailed then it can be replaced but there is no replacement in case of software.Software is engineered & not manufactured.The roadmap to building high quality software products is software process.
Software processes are adapted to meet the needs of software engineers and managers as they undertake thedevelopment of a software product.
A software process provides a framework for managing activities that can very easily get out of control.
Different projects require different software processes.
The software engineer's work products (programs, documentation, data) are produced as consequences of theactivities defined by the software process.
The best indicators of how well a software process has worked are the quality,timeliness, and long-term viability of the resulting software product.
Q5.Explain the Different types of Software Measurement Techniques.
Most estimating methodologies are predicated on analogous software programs. Expert opinion is based on experiencefrom similar programs; parametric models stratify internal data based to simulate environments from many analogous programs;engineering builds reference similar experience at the unit level; and cost estimating relationships like parametricmodels regress algorithms from several analogousprograms. Deciding which of these methodologies or combination or methodlogies is the most appropriate for your program usually depends on availability of data. Which is inturn depends onwhere you are in the life cycle or your scope definition.Analogies. Cost and schedule are determined based on data from competed similar efforts. When applying thismethod, it is often difficult to find analogous efforts at the total system level. It may be possible, however, to findanalogous efforts at the subsystem or lower level computer software configuration item/computer softwarecomponent/computer software unit (CSCI/CSC/CSU). Furthermore, You may be able to find completed efforts that are
more or less similar in complexity. If this is the case, a scaling factor may be applied based on expert opinion. After ananalogous effort hasbeen found. Associated data need to be assessed. It is prefereable to use effort rather than cost data;however, if only cost data are available, these costs must be normalized to the same base year as your effort using currentand appropriate inflation indices. As with all methods, the quality of the estimate is directly proportional to the credibilityof the data.Expert (Engineering opinion). Cost and schedule are estimated by determining requiredeffort based on input from personnel with extensive experience on similar programs. Due to the inherent subjectivity of this method, it is especiallyimportant that input from several independent sources be used. It is also important to request only effort data rather thancost.
Q6. Write a Note on Spiral Model.
The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used ininformation technology (IT). This model of development combines the features of the prototyping model and the waterfallmodel. The spiral model is favored for large, expensive, and complicated projects.The steps in the spiral model can be generalized as follows:
The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of usersrepresenting all the external or internal users and other aspects of the existing system.2.
A preliminary design is created for the new system.3.
A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, andrepresents an approximation of the characteristics of the final product.4.
A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses,and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4)constructing and testing the second prototype.5.
At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involvedevelopment cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result ina less-than-satisfactory final product.6.
The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype isdeveloped from it according to the fourfold procedure outlined above.7.
The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.8.
The final system is constructed, based on the refined prototype.The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scalefailures and to minimize downtime.

Activity (19)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
jerry_jed liked this
jerry_jed liked this
Mayur Palherkar liked this
Krishna Tiwari liked this
Anand YA liked this
Aepi Thakar liked this
satna_kheriya liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->