soft engg assign 1
TRANSCRIPT
-
7/28/2019 Soft Engg Assign 1
1/17
-
7/28/2019 Soft Engg Assign 1
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) -
7/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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
-
7/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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) -
7/28/2019 Soft Engg Assign 1
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) -
7/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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 -
7/28/2019 Soft Engg Assign 1
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.
-
7/28/2019 Soft Engg Assign 1
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
-
7/28/2019 Soft Engg Assign 1
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