AssignmentCover Sheet Faculty of Science and Technology

Student ID 30121112 Student Name Sadia Aslam

Course Code ITECH 6501 Course Name Ecommerce Management

Date Submitted 24-04-2015 Lecturer’s Name Beulah Moses

Tutor’s Name Haider Al Khalidi

ASSIGNMENT TITLE :Principals of software engineering

PLAGIARISM
Plagiarism is the presentation of the expressed thought or work of another person as though it is one'sownwithout
properlyacknowledgingthatperson. Youmustnotallowotherstudentstocopyyourworkandmusttakecareto
safeguardagainstthishappening.
Plagiarismisaseriousoffence.AssetoutinUniversityRegulation6.1.1.,studentswhoarecaughtplagiarizingwill,
forafirstoffence,begivenazeromarkforthattask.Asecondoffencewillresultinafailinggradeforthe Course(s)
involvedandanysubsequentoffencewillbereferredtotheStudentDisciplineCommittee.

Declaration
Exceptwhereappropriatelyacknowledged,thisassignmentismyownwork,hasbeenexpressedinmy
ownwordsandhas notpreviouslybeensubmittedforassessment.I havealsoretaineda copyofthis
Assessmentpieceformyownrecords.
Signature:Sadia Aslam Date:22-04-2015

Feedback/Assessment:

LECTURER’S SIGNATURE: DATE:

Faculty of Science and Technology

Federation University ,Mt Helen Campus
POBox663 Ballarat Vic
3353CRICOSProviderNumber00103D

The Laws of Software Engineering

 ABSTRACT
The purpose behind these studies is to examine and explore different laws of software engineering within an
industry. There are two main aspects of this research. The first aspect is to explain the four laws of software
engineering, namely, the Glass Law, the Parnas Law, the Corbato Law and the Conway Law. And the second
aspect of the assignment is to observe the differences between observation, law and theory. In spite of every last
one of the advances in the programming devices, there appear to be a few persevering truths about programming
improvement. By understanding these laws, we can uproot a percentage of the riddle of the procedure. Many
scientists have discussed laws that appear to apply by and large to the craft of programming.

Glass Law

Requirement deficiencies are the prime source of project failures. (L1)

.
The Glass law stated as the requirements deficiencies is the prime source of project failures(1998).According to
this gathering the required needs of a project is basic step which characterizes what the task should do. For
completing a project successfully, satisfying all the requirements of a project should be the most important thing.
Framework outline is based on the information of requirements. Any requirement which is incomplete or very
complex to apply will lead to the project failures. He stated the above law after researching many unsuccessful
projects. For completing a successful project setting the goals correctly and accurately should be a challenging
task. Lack of communication between client and software or inexperienced analysts can be the general reason for
failing projects. We have to calculate the expense of the undertaking project, level of the task and consistency
while assembling the requirements of the project. The law expresses that the inadequate or wrong meaning of
requirements is the significant reason for the project failure.

So as per glass law the requirements for a task ought to be obviously characterized so that the project is done
effectively. According to waterfall model every stage ought to be totally fulfilling the needs of that stage in
order to go to next stage. so the glass law is applicable and valid for waterfall model as the requirement stage is
completely fulfilled in this model. The Agile methodology can be applied by using the glass law. In the Agile
technique the requirements are characterized in early stage, so there is no issue of lacking requirements.

Glass found that there were dreadfully numerous requirements, they were uncertain because of recently
modifications. This suggests that there is a connection between the nature of prerequisites and the project result.
By accomplishing the requirements of the project appropriately the number of errors will be reduced. And it will
be less pricey to correct the errors in the start of any project.
This law communicates that every method that chooses the properties of a particular structure that should have.
The setup is in perspective of information process and makes as per essentials. It is considering inadequacies of
the necessities. Also, Incorrect requirements or data makes the inconveniences being produced methodology in
perspective of the unlucky deficiency of understanding what decisively customer need and misguided judgments
what customer elucidate about prerequisites. This law was happened in history in three assignment
dissatisfaction, for instance, Denver air terminal, Florida State, Federal Aviation Administration. All these have
wobbly, obscure, and insufficient requirements as well.

In any project a few sorts of mistakes can be happened regarding requirements of project.

1. Correspondence / Communication

In the past stage there was a misconception in expressing necessities.

2. Completeness

There was a deficiency in handling the requirements communicated in the past stage.

3. Consistency

Requirements of the project were perceived completely but In the following stage some theoretical errors
were made.

4. Administrative

The necessities were well seen, there may be some administrative blunders in actualizing the requirements
properly at the following stage

Example:

A software organization, Virtusa made a software program for its customer but after some days the product did
not acted according to the requirement of the customers. So the software needed to inspect again, the outcome
was the disappointment in giving the complete requirements by the customer. Finally the product was a
disappointment because of requirements insufficiencies.

Parnas
 Only what is hidden can be changed without risk. (L8)

During 1972 David Parnas gave the concept of information hiding in software modular programming. This
principal is commonly accepted and used in software engineering, which supposes that unnecessary and pointless
information of software should be kept covered at a certain level [Parnas and Clements, 1986]. The cause for
hiding the details is just to make it possible to modify the implementation without breaking dependent policies.
At the point when individuals say that thought is concealing usage data, they don't propose "hiding" in the sense
to make it tough to find. . What they actually mean is separate implementation details from public interface, to
keep the interface simple, to the point, and controllable.
EXAMPLE: Much the same as the most of the basic parts of an auto car are hidden and just offers a genuinely
simple arrangement of controls to work them, similarly a software module also hide the greater part of its
usefulness somewhere down in its entrails and just uncovered a predetermined number of access systems to drive
it. Suppose you have to operate a car with its internal engine you'd have a truly hard time watching out for the
traffic on the way.
In software engineering Abstraction can also used as equivalent expression for information hiding. Extraordinary
features and unshared data of software are kept hidden at lesser level in abstraction. A simple and uncomplicated
interface can have the effect between an effective task and a fizzled version. On the off chance that you have to
keep a worth around, you utilize a worldwide variable.

Parnas watched the work of Philips designers connected a traditional heuristic for programming plan: every
outlined module was of little measurements, autonomously coded and ready to be effortlessly caught on. Parnas
theorized that to enhance viability of programming frameworks, the module interface needed to demonstrate the
minimum conceivable data concerning its execution. Parnas did not complete any experimental studies to
approve this law. Numerous scientists have utilized it yet have neither reproduced nor distributed noteworthy
results for demonstrating the all inclusive legitimacy for this law. In a module concealing programming
undertaking choices so that their substance is free from others and their interface don't rely on upon the
progressions of module substance.

Corbató

Productivity and reliability depend on the length of a program’s text, independent of language level used.
(L12)
Corbato law expresses that the normal measure of the effectiveness of programming and the degree to which
programming yields the same results over a time of time relies on upon the length of a program's content and has
nothing to do with the dialect level that has been utilized. Dialects may be of two levels. Abnormal state dialects
are the scripting languages that are seen by us, for example, Java, C++ and so on though the low level dialects
are the PC interface dialects which are just of utilization of the PC and are not seen by us.

As per Corbato, the length of a program's content measures its efficiency and dependability, regardless of the
utilization of abnormal state dialects or the low level dialects.

EXAMPLE: While creating programming, the software engineer may utilize Java for key programming stages.
The efficiency and dependability of the product rely on upon the how long the system is and not the utilization of
the dialect.

Conway

A system reflects the organizational structure that built it. (LI6)

Melvin Conway introduced this law first time in 1968. Conway laws stated as a system reflect the organizational
structure that built in. In other words we can say that the design of a system is a copy of its organization design.
And structure of a system is determined by its team structure. We can realize team capabilities by checking the
software they are creating, if software is good and quick then team is good and quick and if software is slow then
team is not good in its working. The system structure reveals the status and control relationship of the customers
and organizations.
For example if there are two software modules A and B. they cannot work properly with each other until the
workers and designer of module A communicates with the workers and designer of module B. hence the
software interface structure will show similarity with the organization social structure.
In any organization if the working group does not communicate properly then the software system framework
will not work accurately. This is logical when one believe that software development is an extremely human
concentrated methodology with a huge number of choices and connections needed. Conway’s law has been
around for long time going back to the 1960’s.
We can understand Open Source with the help of Conway’s Law. The term Open Source is just appear as
product methodology (the source code), however it doesn't comprehend the procedure itself. The motivation
behind why software designers are forced to eject the source code is that they need to co-work with engineers
they will never meet or think about. At the point when someone is creating software programming for the
Internet, this issue is extremely intense. For example, SMTP, which is a network standard, is difficult to develop
without open source implementation. Source code can be released just to those individuals who need to
incorporate on the project, which is the place the idea of group source emerges. At long last, inside an open
source extend, one can tell the spots of most significant interest, or why the gatherings of individuals have met
up, by seeing what parts have been most completely created and made most adaptable and with the most in
reverse similarity. The advantage is that the association will draw the new construction modeling out of the code
in light of the fact that it is the just way the groups can become successful. Imminent organizations along these
lines give the chance to figure groups with a higher feeling of possession too. Such a variety of organizations
endeavor to accomplish quality through methodology, administration, agendas, sign offs, and numerous different
obstacles to conveyance. The truth is the most ideal approach to attain to amazing quality software programming
is to give individuals a feeling of proprietorship in the code they compose. On the off chance that you adjust your
association around your structural engineering and make groups that completely own a segment, then the
characteristic result is a superior quality item. Quality that gets to be intrinsic and claimed by the individuals
making the product, without overwhelming methods that effect the proficiency of the group.
Example: if a project team takes up the project of building a valid database system for a company that is new to
databases and the company itself has a badly working database system, it can very well be predicted that they
might not build a good database system for their clients.

Explain the relationship between observation, law and theory. Illustrate your answer with
examples – with at least one from software engineering.

\
Observation, Law & Theory: These adjustments among the plans and ideas also. Laws, perception and the
hypotheses have their own focal points and qualities that ought to be seen ahead of time that how all these work
together.
The above all else is the perception that gives the data what is going on or as it were what is occurring. Be that as
it may, this is additionally demonstrating some sensible results in which researcher watch issues and matters
above period just to complete the precise importance of hypothesis. Perception can be put on the approved
association the fundamental piece of concerning all the three related ideas. All are depended open one another
one can't finish exclusively. On the other hand, despite the association, there are real.
Observation:
Observation n is method for social
occasion information by observing,
conduct, occasions, or taking note of
physical qualities in their common
setting. In observational exploration,
we don't manage what individuals need us
to know (report toward oneself
measures). Maybe, we manage real
individuals in genuine circumstances.
Individuals are seen in real life.

Law:
law is a brief illumination of a lumbering measure of elucidations or tests. Law can gage that what will happen
next or what could be conceivable however on the other hand theory needs to give the reason that why this is
happened. Law is reliably stays for what and Theory is stands for - Why.(Roadkill july 2006).Law is the
execution and the discernment that constantly stays for the wide time improvements in system. Laws are the
rules or heading of a culture that is there planned to shield specific single and solidified advantages human rights
and endorsements. Each one of they were going to see after important discernment and thought. In any case,
Indication and confirmation is the
important law making technique.
At last, measures are the most
elevated fact or reality in an
open humanity. They declare
pleasantness, and they
are absolutely utilitarian to
all. Law is the fundamental part in every human's life as they can grant their rights. In any case it is necessary to
understand that if law is giving the agree to drive the auto it infers an individual should strict on the law and the
benefit moreover need to know how they drive especially in the action.

Theory:
Theories are regularly viewed as similarly as straight answer to reflection or perception. They cover
extraordinary hypotheses that were likely to require spared phenomena. The recognizable thing is that they are
built proposal associated with those phenomena. Incalculable by and large specified the speculations simply like
Creationism furthermore basically essential gathering of individual supposition. The reason is that they are
missing of precise and genuine evidences. Hypotheses can be measured as the second stage or stage in the
development of data.

Example: in a University’s database system some of the student information has been repeated more than once
which is causing the problem of data redundancy. The system is updated a couple of times, and the same
problem occurs. The problem becomes an observation. The administration then looks for what exactly is going
wrong. When they figure out that the data redundancy is causing system break down, this becomes a law. The
solution to this law however becomes the theory as to why is this problem occurring.

Explain the relationship between Law, Method and Tool.

 Law, Method and Tools
A portion of the understandings and practices are such that they can be named as laws. It can be additionally said
that not very many are indistinguishable furthermore don't remains for any evidence or proof. They are helpful
and significant additionally, in any case, and we will specify to them as moralities and morals. Greatest records
on processing science endeavour to arrange in any event a few theories, values, from which in conjunction with
principles, systems have been determined. We will utilize the expression "technique" to incorporate what other
individuals may call a system or practice. Strategies are managed by apparatuses. Trademark devices are a
stopwatch, a computing sticky tape, or an optical magnifying lens. Apparatuses are frequently processor
programs.
Example: For implementing a new database system, the organization must follow a particular method of doing
so which may include identifying the key requirements in form of product entities, getting them to normalized
form, making an ER diagram and building the database on the mySQL server. The manner in which everything
has to be done is the method and the tools are the equipments that help in the carrying out of method, which in
this case is the mySQL server.

Reference:

1. Endres, A & Rombach, D. (2003). A Handbook of Software and Systems Engineering: Empirical
Observations, Laws and Theories. Addison-Wesley Professional. ISBN: 9780321154200 nce:
2. van Vliet, H. (2008). Software engineering : principles and practice (3rd ed). John Wiley & Sons. ISBN:
9780470031469

3. Glass, R.L.: Software Runaways. Lessons Learned from Massive Software Project Failures. Upper Saddle
River, NJ: Prentice Hall 1998
4. Parnas D.L. (December 1985). "Software aspects of strategic defense systems". Comm ACM 28 (12): 1326–
35.

5. Yourdon, E. N., and Constantine, L. L. Structured Design (Prentice Hall, 1978), p. 400

http://www.studymode.com/course-notes/Software-Engineering-1570342.html
6. Noel, Al. 2014, Some "Laws" of Software Development.

7. De Lucia, A., Ferrucci, F., Tortora, G., &Tucci, M. (Eds.). (2008). Emerging methods, technologies and
process management in software engineering. John Wiley & Sons.