module 7

module 6

module 5

What is software construction?

•‘Construction’ refers to the hands-on part of creating something.

•Also known as implementation / coding and debugging & verification and validation (testing).

•Generally focus at coding, debugging, some detailed design and some testing (esp. unit testing).

•Quality of construction substantially affects the quality of the software.

Programming Principles

Programming is a skill best acquired by practice and example rather than from books. The remarks given here are therefore quite inadequate. [The word ``inadequate'' is very faint in the ms., and may have been deliberately whited out.]
If it is desired to give a definition of programming, one might say that it is an activity by which a digital computer is made to do a man's will, by expressing this will suitably on punched tapes, or whatever other input medium is accepted by the machine. This is normally achieved by working up from relatively simple requirements to more complex ones. Thus for instance if it is desired to do a Fourier analysis on the machine it would be as well to arrange first that one can calculate cosines on it. For each process that one wishes the machine to be able to carry out one constructs a `routine' for the process. This consists mainly of a set of instructions, which are obeyed by the machine in the process. It is not usual however to reckon all the instructions obeyed in the process as part of the routine. Many of them will belong to other routines, previously constructed and carrying out simpler processes. Thus for instance the Fourier analysis process would involve obeying instructions in the routine for forming cosines as well as ones in the analysis routine proper. In a case like this the cosines routine is described as a `subroutine' of the analysis routine. The subroutines of any routine may themselves have subroutines. This is like the case of the bigger and lesser fleas. I am not sure of the exact meaning the poet attached to the phrase `and so ad infinitum', but am inclined to think that he meant there was no limit that one could assign to the length of a parasitic chain of fleas, rather than that he believed in infinitely long chains. This certainly is the case with subroutines. One always eventually comes down to a routine without subroutines.
[The previous paragraph would have to be amended somewhat in the light of modern practice. Currently, digital Fourier analysis generally uses FFT algorithms which do not involve any explicit evaluations of cosines (or other trigonometric functions); evidently Turing was not familiar with these approaches, though the basic idea has been traced back to the 19th century. Likewise, his final statement that ``One always eventually comes down to a routine without subroutines'' needs some modification in the case of recursive routines, or sets of mutually recursive routines -- one always eventually comes down to a routine which does not invoke any subroutines (at least if the computation ever terminates!) but that is a somewhat different thing.]
What is normally required of a routine is that a certain function of the state of the machine shall be calculated and stored in a given place, the majority of the content of the store being unaffected by the process, and the routine not being dependent on this part having any particular content. It is usual also for the other part of the store to be divided into a part which is altered in the process but not greatly restricted as to its original content, and a part which is unaltered in its content throughout, and such that the correct working of the routine depends on this part having a particular content. The former can be described as `the working space for the routine' and the latter as `the space occupied by the routine'.
Applying this to the Mark II machine, the routines usually `occupy' various tracks of the magnetic store. The working space includes all the electronic store, with the exception of PERM, which can equally well be reckoned as working space which is never really altered, or as a part common to all routines. The first two pages of the electronic store are also somewhat exceptional, if normal conventions are used, as they are only altered when one is copying new routines from the magnetic store onto them.
These definitions do not really help the beginner. Something more specific is needed. I describe below the principal steps which I use in programming, in the hope they will be of some small assistance.

(i) Make a plan

This rather baffling piece of advice is often offered in identical words to the beginner in chess. Likewise the writer of a short story is advised to `think of a plot' or an inventor to `have an idea'. These things are not the kind that we try to make rules about. In this case however some assistance can be given, by describing the decisions that go to make up the plan.
a) If it is a genuine numerical computation that is involved (rather than e.g. the solution of a puzzle) one must decide what mathematical formulae are to be used. For example if one were calculating the Bessel function one would have, amongst others, the alternatives of using the power series in , various other power series with other origins, interpolation from a table, various definite integrals, integration of the differential equation by small arcs, and asymptotic formulae. It may be necessary to give some small consideration to a number of the alternative methods.
b) Some idea should be formed as to the supply and demand of the economic factors involved. A balance must always be struck between the following incompatible desires

• To carry the process through as fast as possible
• To use as little storage space as possible
• To finish the programming as quickly as possible
• To achieve the maximum possible accuracy

We may express this by saying that machine time, storage space, programmers' time and inaccuracy of results all cost something. The plan should take this into account to some extent, though a true optimum cannot be achieved except by chance, since programmers' time is involved, so that a determination of the optimum would defeat its own ends. The `state of the market' for these economic factors will vary greatly from problem to problem. For instance there will be an enormous proportion of problems (40% perhaps) where there is no question of using the whole storage capacity of the machine, so that space is almost free. With other types of problem one could easily use ten million digits of storage and still not be satisfied. The space shortage applies mainly to working space rather than to the space occupied by the routines. Since these usually have to be written down by someone this in itself has a limiting effect. [The statement that instructions are not likely to cause a space shortage is also somewhat at odds with current practice.] Speed will usually be a factor worth consideration, though there are many `fiddling' jobs where it is almost irrelevant. For instance the calculation of tabular values for functions which are to be stored in the machine and later used for interpolation, would usually be in this class. Programmers' time will usually be the main factor in special jobs, but is relatively unimportant in fundamental routines which are used in most jobs. Accuracy may compete with machine time e.g. over such questions as the number of terms to be taken in a series, and with space over the question as to whether 20 or 40 digits of a number should be stored.
c) The available storage space must be apportioned to various duties. This will apply both to magnetic and electronic storage. The magnetic storage will probably be mainly either working space or unused. It should be possible to estimate the space occupied by instructions to within say two tracks, for a large part will probably be previously constructed programmes, occupying a known number of tracks. The quantities to be held in the working space should if possible be arranged in packets which it is convenient to use all at once, and which can be packed into a track of a half-track or quarter-track. For instance when multiplying matrices it might be convenient to partition the matrices into four rowed or eight rowed square matrices and keep each either in a track or a quarter-track. The apportionment of the electronic store is partly ruled by the conventions we have introduced, but there is still a good deal of freedom, e.g. if eight [electronic] pages are available then pages 4, 5, 6 can be used for systematic working space and may be used for various different purposes that require systematic working space.
The beginner will do well to ask for advice concerning plans. Bad plans lead to programmes being thrown away, wasting valuable programmers' time.
d) If questions of time are at all critical the `plan' should include a little detailed programming, i.e. the writing down of a few instructions. It should be fairly evident which operations are likely to consume most of the time, and often these will consist of a small number of instructions repeated again and again. In these cases the few instructions in question should be written down so as to give an estimate of the time, and help decide whether the plans as a whole is satisfactory. Very often the `omission of counting method'  should be applied
e) If one cannot think of any way, good or bad, for doing a job, it is a good thing to try and think how one would do it oneself with pencil and paper. If one can think of such a method it can usually be translated into a method which could be applied to the machine.

(ii) Break the problem down

This in effect means to decide which parts of the problem should be made into definite subroutines. The purpose of this is partly to make the problem easier to think about, the remaining work consisting of a number of `limited objective' problems. Another reason for breaking down is to facilitate the solution of other problems by the provision of useful subroutines. For instance if the problem on hand were the calculation of Bessel functions and it had already been decided to use the differential equation, it might be wise to make and use a subroutine for the solution of linear second order differential equations. This subroutine would in general be useful in connection with other subroutines which calculate the coefficients of the equation.

(iii) Do the programming of the new subroutines

It is better to do the programming of the subroutines before that of the main routine, because there will be a number of details which will only be known after the subroutine has been made, e.g. scale factors applied to the results, number of pages occupied by the subroutine, etc. It also frequently happens in the making of the subroutine that some relatively small change in its proposed properties is desirable. Changes of these details may put the main routine seriously out if it were made first. There is a danger that this procedure may result in one's `not seeing the wood for the trees', but this should not happen if the original plan was well thought out. The programming of each subroutine can itself be divided into parts.
a) As with programming a whole problem a plan is needed for a subroutine. A convenient aid in this is the `block schematic diagram'. This consists of a number of operations described in English (or any private notation that the programmer prefers) and joined by arrows. Two arrows may leave a point where a test occurs, or more if a variable control transfer number is used. Notes may also be made showing what is tested, or how many times a loop is to be traversed  . 
b) The operations appearing as blocks in a) may be replaced by actual instructions. It is usually not worth while at first to write down more than the last two characters of the (presumptive) instruction, i.e. the B line and function parts. These are quite enough to remind one of what was the purpose of the instruction.
c) One may then write the instructions into a page, deciding at the same time what are to be the addresses involved. Some of the finer points of this are described in the `hints' in the next section.
d) When the programme is complete, check sheets must be made. This process has already been described . It is often advisable to start making check sheets long before the program is complete; one should in fact begin them as soon as one feels that one has got into a muddle. It is often possible to work out most of the programme on the check sheets and afterwards transfer back onto the page or pages of instructions.

module 4

Principles of Design

The Principles are concepts used to organize or arrange the structural elements of design. Again, the way in which these principles are applied affects the expressive content, or the message of the work.

The principles are:

Balance

Proportion

Rhythm

Emphasis

Unity

Balance

Balance is the concept of visual equilibrium, and relates to our physical sense of balance. It is a reconciliation of opposing forces in a composition that results in visual stability. Most successful compositions achieve balance in one of two ways: symmetrically or asymmetrically. Balance in a three dimensional object is easy to understand; if balance isn't achieved, the object tips over. To understand balance in a two dimensional composition, we must use our imaginations to carry this three dimensional analogy forward to the flat surface.

Symmetrical balance can be described as having equal "weight" on equal sides of a centrally placed fulcrum. It may also be referred to as formal balance. When the elements are arranged equally on either side of a central axis, the result is Bilateral symmetry. This axis may be horizontal or vertical. It is also possible to build formal balance by arranging elements equally around a central point , resulting in radial symmetry.

There is a variant of symmetrical balance called approximate symmetry in which equivalent but not identical forms are arranged around the fulcrum line.

Asymmetrical balance, also called informal balance, is more complex and difficult to envisage. It involves placement of objects in a way that will allow objects of varying visual weight to balance one another around a fulcrum point. This can be best imagined by envisioning a literal balance scale that can represent the visual "weights" that can be imagined in a two dimensional composition. For example, it is possible to balance a heavy weight with a cluster of lighter weights on equal sides of a fulcrum; in a picture, this might be a cluster of small objects balanced by a large object. It is also possible to imagine objects of equal weight but different mass (such as a large mass of feathers versus a small mass of stones) on equal sides of a fulcrum. Unequal weights can even be balanced by shifting the fulcrum point on our imaginary scale.

Whether the solution is simple or complex, some form of balance can be identified in most successful compositions. For a further discussion of balance in design see these sites:

 

Proportion

Proportion refers to the relative size and scale of the various elements in a design. The issue is the relationship between objects, or parts, of a whole. This means that it is necessary to discuss proportion in terms of the context or standard used to determine proportions.

Our most universal standard of measurement is the human body; that is, our experience of living in our own bodies. We judge the appropriateness of size of objects by that measure. For example, a sofa in the form of a hand is startling because of the distortion of expected proportion, and becomes the center of attention in the room. Architectural spaces intended to impress are usually scaled to a size that dwarfs the human viewer. This is a device often used in public spaces, such as churches or centers of government. The same principle is often applied to corporate spaces through which the enterprise wishes to impress customers with its power and invincibility.

Rhythm

Rhythm can be described as timed movement through space; an easy, connected path along which the eye follows a regular arrangement of motifs. The presence of rhythm creates predictability and order in a composition. Visual rhythm may be best understood by relating it to rhythm in sound. This link will take you to a video clip and explanation of how the sound of a Nigerian "talking drum" follows the intonation and rhythm of speech. Another, more visual example, can be found by clicking on this link and selecting the clip of your choice. These demonstrate the blending of rhythm, movement,and visual form.

Rhythm depends largely upon the elements of pattern and movement to achieve its effects. The parallels between rhythm in sound/ music are very exact to the idea of rhythm in a visual composition. The difference is that the timed "beat" is sensed by the eyes rather than the ears.

Visual rhythm can be created in a number of ways. Linear rhythm refers to the characteristic flow of the individual line. Accomplished artists have a recognizable manner of putting down the lines of their drawings that is a direct result of the characteristic gesture used to make those lines, which, if observed, can be seen to have a rhythm of its own. Linear rhythm is not as dependent on pattern, but is more dependent on timed movement of the viewer's eye.

Repetition involves the use of patterning to achieve timed movement and a visual "beat". This repetition may be a clear repetition of elements in a composition, or it may be a more subtle kind of repetition that can be observed in the underlying structure of the image.

Alternation is a specific instance of patterning in which a sequence of repeating motifs are presented in turn; (short/long; fat/thin; round/square; dark/light).

Gradation employs a series of motifs patterned to relate to one another through a regular progression of steps. This may be a gradation of shape or color. Some shape gradations may in fact create a sequence of events, not unlike a series of images in a comic strip.

Emphasis

Emphasis is also referred to as point of focus, or interruption. It marks the locations in a composition which most strongly draw the viewers attention. Usually there is a primary, or main, point of emphasis, with perhaps secondary emphases in other parts of the composition. The emphasis is usually an interruption in the fundamental pattern or movement of the viewers eye through the composition, or a break in the rhythm.

The artist or designer uses emphasis to call attention to something, or to vary the composition in order to hold the viewers interest by providing visual "surprises."

Emphasis can be achieved in a number of ways. Repetition creates emphasis by calling attention to the repeated element through sheer force of numbers. If a color is repeated across a map, the places where certain colors cluster will attract your attention, in this instance graphing varying rates of mortality from cardiovascular disease.

Contrast achieves emphasis by setting the point of emphasis apart from the rest of its background. Various kinds of contrasts are possible. The use of a neutral background isolates the point of emphasis.

Contrast of color, texture, or shape will call attention to a specific point.

Contrast of size or scale will as well.

Placement in a strategic position will call attention to a particular element of a design.

Prolonged visual involvement through intricacy (contrast of detail) is a more unusual form of emphasis, not as commonly used in Euro-American design, though it is common in many other cultures. In this case, many points of emphasis are created that are to be discovered through close attention to the intricacies of the design.

Unity

Unity is the underlying principle that summarizes all of the principles and elements of design. It refers to the coherence of the whole, the sense that all of the parts are working together to achieve a common result; a harmony of all the parts.

Unity can be achieved through the effective and consistent use of any of the elements, but pattern-- that is, underlying structure-- is the most fundamental element for a strong sense of unity. Consistency of form and color are also powerful tools that can pull a composition together.
However, unity also exists in variety. It is not necessary for all of the elements to be identical in form providing they have a common quality of meaning or style. For example, fashions from a specific period share common features of silhouette, materials, and color that identify the style of the day, or the look of a particular designer.

Unity can also be a matter of concept. The elements and principles can be selected to support the intended function of the designed object; the purpose of the object unifies the design.

In contrast, the proportions of a private home are usually more in scale with human measure, and as a result it appears more friendly, comfortable, less intimidating.

Use of appropriate scale in surface design is also important. For example, an overly large textile design can overwhelm the form of a garment or a piece of furniture. surprising aspect of proportion is the way ideal proportions can vary for the human body itself. Styles change in bodies as they do in clothing. Prior to the 16th century, for example, the female body ideally had large hips and belly. Only later was a small waistline stressed.

n the 17th century and many other periods, the ideal body was much heavier than we would accept today.

f course, in the last 35 years the ideal personified by the fashion model has fostered a standard which idealizes exceptionally slender body proportions for women. In this century, sports have provided models for ideal male body proportions. Beginning with the rise of televised football in the 1960's, and the subsequent fitness boom, an increasingly exaggerated muscular silhouette, corresponding to that of the uniformed and padded football player, was presented as the ultimate male form. Only in this period could Arnold Schwartzenegger have represented the heroic ideal body image. This trend reached its most extreme form in the late 1970s and early 1980s. Since that time the emergence of basketball as the predominant American sport has led to a more naturally proportioned fit body ideal for men.

In addition, artists frequently take liberties with the natural proportions of the human body to achieve their expressive goals. A well known classic example is Michaelangelo's David, in which distortions of proportion are used by the artist to depict both the youthfulness of the boy David, together with the power of the hero about to conquer the giant Goliath. The surrealist painter Magritte often used distortions of proportions to create striking effects.

module 3

PART 1

The best method to study this module is by drawing a mind map. In this module, it focus more on RE process. In RE process, there's 5 main tasks. So, by drawing mind map,we can easily remember all different types of requirements.


Lessons

Concept of Requirements

According to IEEE Standard Glossary of Software Engineering Terminology (IEEE, 1990), requirement means a condition or capability needed by a user to solve a problem or achieve an objective.


Two types of requirement:


1) Functional Requirements (FR)
Definition : A requirement that specifies a function that a system component must be able to perform.


Important points :

• Describe services a system or component of a system should perform
• MUST NOT include quality statement such as 'fast, 'efficient', 'usable', 'reliable' etc.

2) Non-Functional Requirement (NFR)
Definition : A requirement that specifies quality characteristic of the software and constraints of the software to be developed and/or process to develop the software.

Important points :

• Example quality attributes:

- Reliability
- Security
- Performance
- Safety

• Example constraints :

- Skill-set of the developers
- Target operating environment
- Programming language to develop the system
- Software process that should be followed


Requirement Engineering

What is Requirements Engineering (RE)?

• "The process of developing a requirements specification" (Pohl, 1996)
• "To cover all activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. (Sommerville & Sawyer, 1997)

RE Process

Requirement Development
1) Requirement Elicitation
Meaning of Elicitation : A stimulation that bring forth a class of behavior


4 components of requirements elicitation:

• Understanding application domain
• Understanding problem to be solved
• Understanding business processes in an organization
• Understanding the needs and constraints of the stakeholders

2) Requirements Analysis and Negotiation


- Build analysis model
Generic elements common to most requirements models:

• Scenario-based elements (Processing narrative of software function)
• Class-based elements (Implied by scenario)
• Behavioral elements (State diagram)
• Flow-oriented elements (DFD)

- Prioritizing Requirements
Techniques of requirements prioritization

1. Prioritization scale
2. QFD
3. Semi quantitative Analytical Approach

- Conflict & Conflict Resolution
Technique to identify conflicts and overlaps --> Interaction matrix

- Negotiating Requirements

Negotiating Guidelines :

1. Recognize that it's not a competition
2. Map out a strategy
3. Listen actively
4. Focus on the other party's
5. Don't let it get personal
6. Be creative
7. Be ready to commit and move on

3) Requirements Specification


- To build the requirements document : SRS (Software Requirements Specification)
- Should involve technical writers


SRS
Attributes of a well-written SRS

• Correct
• Unambiguous
• Complete
• Consistent
• Testable
• Traceable

4) Requirements Verification and Validation


Definition : Requirements verification is a process of checking that a product meets its specifications
Requirements validation is a process of checking that a product meets the needs and expectation of the customer.

V & V Techniques


1. Revives the requirements specification
- Desk check
- Walk through
- Inspection
- Checklist
2. Prototyping
3. Acceptance Tests


Requirement Management

- Managing changes to requirements
- Managing configuration of requirements and requirements document
- Maintaining requirements traceability
- Tracking requirements status

Part 2

The purpose of

System Requirements Analysis is to obtain a thorough and detailed understanding of the business need as defined in Project Origination and captured in the Business Case, and to break it down into discrete requirements, which are then clearly defined, reviewed and agreed upon with the Customer Decision-Makers. During System Requirements Analysis, the framework for the application is developed, providing the foundation for all future design and development

efforts. System Requirements Analysis can be a challenging phase, because all of the major Customers and their interests are brought into the process of determining requirements. The

quality of the final product is highly dependent on the effectiveness of the requirements identification process. Since the requirements form the basis for all future work on the project, from design and development to testing and documentation, it is of the utmost importance that the Project Team create a complete and accurate representation of all requirements that

the system must accommodate. Accurately identified requirements result from effective communication and collaboration among all members of the Project Team, and provide the best chance of creating a system that fully satisfies the needs of the Customers.

This phase consists of the following processes:

_ Prepare for System Requirements Analysis, where steps are taken to ensure that the project environment and Project Team members are adequately prepared to both capture and analyze the system requirements;

_ Determine Business Requirements, where in-scope and

Out-of-scope business requirements are identified, business

Rules are defined and documented, and interfaces to and

From the new application are discussed;

_ Define Process Model, where a pictorial top-down

Representation of the major business processes that

Interact with the system is diagrammed and decomposed

Into manageable functions and sub-functions until no

Further breakdown is feasible;

_ Define Logical Data Model, where data that supports

the processes and business rules is logically modeled,

identifying entities and their relationships to other entities,

and defining attributes with their business definitions;

_ Reconcile Business Requirements With Models, where

the Project Team ensures that the Process and Logical

Data Models accommodate all requirements and business

rules;

_ Produce Functional Specification, where interfaces,

processes and data are merged to describe systematically

how the Consumer will use the application, and how data

will be retrieved, processed and stored.