UNIT 2 MODULE 1 Software and System Development Topic : Software Development Compiled by: Careene McCallum-Rodney

UNIT 2 MODULE 1

Software and System Software and System DevelopmentDevelopment

Topic : Software Development

Compiled by:Careene McCallum-Rodney

INTRODUCTION TO SOFTWARE DEVELOPMENT______________________________________________________

Every field of study has its own name for the systematic method used to solve problems by designing suitable solutions. In the world of software, the procedure is called the software development procedure.

Software Development ensures that the software produced meet the specification required.

This aspect of the syllabus is really focusing on software engineering. Software Engineering is concerned with the theories, methods and tools which are needed to develop the software for computers.

The need for a structured software

development process

SUB-TOPIC

Specific ObjectiveStudents should be able to explain the reasons for a

structured approach to software development process

The need for a structured software

development processIncreased Increased

Dependence of many Dependence of many organizations on their organizations on their

computer systemcomputer system

Crises in Crises in previous previous developmentsdevelopments

Requirements for Requirements for standard interfacesstandard interfaces

Need for tighter Need for tighter control and control and

management of management of processprocess

Increasing cost of software development

Dissatisfaction of users and management with

the quality and suitability of the

softwareIncreasing length and

complexity of the software

ExitHome

1. Increased Dependence of many organizations

on their computer systemIn all industrialized countries, and increasingly in developing

countries, computer systems are economically critical. More and

more products incorporate computers in some form. Educational,

administrative and health care systems are dependent on computer

systems. The software in these systems represents a large and

increasing proportion of the total system costs. The effective

functioning of modern economic and political systems therefore

depends on the ability to produce software in a cost effective way.

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments

A "large" software system is a system that contains more than 50,000

lines of high-level language code. It’s those large systems that bring

the software crisis to light. With large software development

projects, the work is done in teams consisting of project managers,

requirements analysts, software engineers, documentation experts,

and programmers. With so many professionals collaborating in an

organized manner on a project, what’s the problem? Why is it that the

team produces fewer than 10 lines of code per day over the average

lifetime of the project? And why are sixty errors found per every

thousand lines of code? Why is one of every three large projects

scrapped before ever being completed? And why is only 1 in 8

finished software projects considered "successful?"



NEXT PREVIOUS

Conflicting requirements have always hindered the software development process. For example, while users demand a large number of features, customers generally want to minimize the amount they must pay for the software and the time required for its development.

The causes of the software crisis were linked to the overall complexity of the software process and the relative immaturity of software engineering as a profession.

A structured software development process is mindful of the Software Crisis, and there are methods being implemented by this process to deal with the crisis.

MAIN MENU


NEXT PREVIOUS

Software Crisis can be categorized as follows:

MAIN MENU

Increasing cost of software development

Dissatisfaction of users and management with the quality and suitability of the

software

Increasing length and complexity of the software

Assignment 1


NEXT PREVIOUS

INCREASING COST OF SOFTWARE DEVELOPMENTThe cost of owning and maintaining software in the 1980’s was twice as expensive as developing the software. During the 1990’s, the cost of ownership and maintenance increased by 30% over the 1980’s.

Not only has software development become more costly (especially for bespoke products), but additionally, many times the projects run over-budget.

Software can be difficult to maintain. Software maintenance accounts for the majority of all software budgets. Many software programs consist of errors that were not realized in the implementation process. When maintaining existing software programs it is threatened by poor design (in terms of coding and documentation) as well as inadequate resources. When this occurs, the development process can be very costly and time consuming.

Changes during design, implementation and installation have a severe impact on cost

MAIN MENU


NEXT PREVIOUS

DISSATISFACTION OF USERS AND MANAGEMENT WITH THE QUALITY AND SUITABILITY OF THE SOFTWARE

Early experience in building large software systems showed that existing

methods of software development were not good enough. Techniques

applicable to small systems could not be scaled up.

Major projects were sometimes years late.

They cost more than were originally predicted, were unreliable, difficult to

maintain and performed poorly.

MAIN MENU


NEXT PREVIOUS

DISSATISFACTION OF USERS AND MANAGEMENT WITH THE QUALITY AND SUITABILITY OF THE SOFTWARE

Three quarters of all large software products delivered to the customer are

failures that are either not used at all, or do not meet the customer’s real

needs or requirements. This is so because software development is often

undertaken with only a vague notion of the customer’s requirements.

Many software efforts have failed because developers lack the essential

formal and detailed description on data, functionality, design constraint and

validation criteria, which can be accessed through frequent communication

between developers and customers.

MAIN MENU


NEXT PREVIOUS

INCREASING LENGTH AND COMPLEXITY OF THE SOFTWARE

Projects were unmanageable and code difficult to maintain.

As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

MAIN MENU


NEXT PREVIOUS

INCREASING LENGTH AND COMPLEXITY OF THE SOFTWARE

Another problem that still exists in software development is the time taken to develop software. Software developers regularly underestimate how long it takes to design, write and test their software. Mostly, this problem still exists because developers are trying to produce massive software products with old tools, outdated methods and inadequate management techniques. Sometimes, the assumptions made is that, if the software is behind schedule, more programmers can be added and thus hasten the process. Adding people to a late software project makes it later. Another contributing factor to the time factor is that project requirements continually changes. The impact of change will vary according to when it was introduced.

MAIN MENU


NEXT PREVIOUS

ASSIGNMENT ONE (Due date: to be discussed)

Write a 800 word essay on Software Crisis. The essay must include:

1. Explanation of at least 2 major software crisis.

2. Recommended solution or minimization of the above crisis.

3. Use the MLA research style (you need to personally research this method) of writing throughout the essay and also for the bibliography.

4. Must use at least 3 books and 2 websites. Special marks are allotted to students who use computer journals or magazines and personally interviewed a software developer or expert.

MAIN MENU

3. Requirements for standard interfaces


When applied to computer software, User Interface Design is also known as Human-Computer Interaction or HCI. While people often think of Interface Design in terms of computers, it also refers to many products where the user interacts with controls or displays. Military aircraft, vehicles, airports, audio equipment, and computer peripherals, are a few products that extensively apply User Interface Design.

The more intuitive the user interface the easier it is to use, and the easier it is to use and the less expensive to use it. The better the user interface the easier it is to train people to use it, reducing your training costs. The better your user interface the less help people will need to use it, reducing your support costs. The better your user interface the more your users will like to use it, increasing their satisfaction with the work that you have done.



A fundamental reality of application development is that the user interface is the system to the users. What users want is for developers to build applications that meet their needs and that are easy to use. Too many developers think that they are artistic geniuses – they do not bother to follow user interface design standards or invest the effort to make their applications usable, instead they mistakenly believe that the important thing is to make the code clever or to use a really interesting color scheme. A good user interface allows people who understand the problem domain to work with the application without having to read the manuals or receive training.



The user interface is often the yardstick by which that system is judged. An interface which is difficult to use will, at best, result in a high level of user error. At worst it will cause the software system to be discarded, irrespective of its functionality. If information is presented in a confusing and misleading way, the user may misunderstand the meaning of an item of information. They may initiate a sequence of actions which corrupt data or cause catastrophic system failure.



These principles govern the structure of user interface:

The structure principle. Your design should organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognizable to users, putting related things together and separating unrelated things, differentiating dissimilar things and making similar things resemble one another. The structure principle is concerned with your overall user interface architecture.

The simplicity principle. Your design should make simple, common tasks simple to do, communicating clearly and simply in the user’s own language, and providing good shortcuts that are meaningfully related to longer procedures.

The visibility principle. Your design should keep all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. Good designs don’t overwhelm users with too many alternatives or confuse them with unneeded information.



The feedback principle. Your design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users.

The tolerance principle. Your design should be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions reasonable.

The reuse principle. Your design should reuse internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember.



ASSIGNMENT TWO – Due Date : To be discussed

This assignment is to be done in groups of two.

Requirements: Seek out a customized or generic software which implements user

interfaces. Write an essay on the strong and weak areas of the interfaces, based on facts. Pictures of the interfaces are to be included. Additionally each group will get a total of 7 minutes to present their analysis of the interface.

Additional marks will be allotted to proof of additional research, presentation, grammar and consistent and correct use of the APA format.

Oral presentation is expected to be organized and properly presented.

4. Need for tighter Control and Management of Process

NEXT PREVIOUS

What is the Software Process?

This is the set of activities and associated results which produce a software

product. These activities are mainly carried out by software engineers.

There are 4 fundamental process activities which are common to all

software processes. These activities are:

1. Software specification

The functionality of the software and constraints on its operation

must be defined.

2. Software Development

The software to meet the specification must be produced.

MAIN MENU


NEXT PREVIOUS

3. Software validation

The software must be authenticated to ensure that it does what the

customer wants.

4. Software evolution

The software must develop to meet changing customer needs.

There are no such thing as a ‘right’ or ‘wrong’ process. Different software

processes decompose these activities in different ways. The timing of

the activities varies as does the results of each activity.

MAIN MENU


NEXT PREVIOUS

WHY IS THERE A NEED FOR THE ABOVE?

• Different organizations use different processes to produce the same

type of product. Different types of product may be produced by an

organization using different processes. However, some processes are

more suitable than others for some types of application. If the wrong

process is used, this will probably reduce the quality of or the

usefulness of the software product to be developed.

•Because there are a variety of different process models used, it is

impossible to produce reliable figures for cost distribution across these

activities. However, modifying software usually takes up more

than 60% of total software costs. This percentage is

MAIN MENU


NEXT PREVIOUS

increasing as more and more software is produced and has to be

maintained.

• Software processes are complex and involves a very large number of

activities. These activities need to be managed appropriately

and efficiently.

Consider the :

1. process characteristics

2. need for process visibility

3. need for risk management

MAIN MENU

PROCESS CHARACTERISTICS

NEXT PREVIOUS

Understandability To what extent is the process explicitly defined and how easy is it to understand to process definition?

Visibility Do the process activities culminate in clear results so that the progress of the process is externally visible?

Supportability To what extent can the process activities be supported by CASE tools?

Acceptability Is the defined process acceptable to and usable by the engineers responsible for producing the software product?

Reliability Is the process designed in such a way that process errors are avoided or trapped before they result in product errors?

Robustness Can the process continue in spite of unexpected problems?

Maintainability Can the process evolve to reflect changing organizational requirements or identified process improvements?

Rapidity How fast can the process of delivering a system form a given specification be completed?

MAIN MENU

NEXT PREVIOUS

NEED FOR PROCESS VISIBILITY

Because of the intangible nature of software systems, software process

managers need documents, reports and reviews to keep track of what

is going on. Each activity must end with the production of some

document. These document make the software process visible.

However, regular document production has some drawbacks:

1. Management needs regular deliverables to assess project progress

The timing of management requirements may not correspond with the

time needed to complete an activity. Extra documents may have to be

produced adding to the cost of the process.

MAIN MENU

NEXT PREVIOUS

2. The need to approve document constrains process iterations

The cost of going back and adapting a complete deliverable are high.

If the problems are discovered during the process, inelegant solutions

are sometimes adopted to avoid the need to change ‘accepted’ project

deliverables.

3. The time required to review and approve a document is significant

There is rarely a smooth transition from one phase of the process to

the next. Development may continue before the previous phase

document has been completed.

NEED FOR PROCESS VISIBILITY

MAIN MENU

NEXT PREVIOUS

Risk is a concept that is difficult to define precisely. Informally, it is simply

something which can go wrong. For example, if the intention is to use

a new programming language, a risk is that the available compilers are

unreliable or do not produce sufficiently efficient object code.

Risks are a consequence of inadequate information. They are resolved

by initiating some actions which discover information that reduces

uncertainty. In the above example, the risk would be resolved by a

market survey to find out which compilers are available and how good

are they. If no suitable system was discovered, the decision to use a

new language must be changed.

NEED FOR RISK MANAGEMENT

MAIN MENU

NEXT PREVIOUS

Risk Management is a method for dealing with project risks, by identifying

and handling them appropriately. This method is on-going and is used

throughout the life of the project.

BASIC APPROACH

• Analysis of project, so that you can identify risks involved.

• For each risk identified, the following steps are taken:

Impact and Probability Analysis (the nature of the risk),

Avoidance Plan ( How to minimize risks), and

Contingency Plan (What to do if it occurs).


MAIN MENU

Risk Management

R isk M anagem ent

R isk A ssessm ent

R isk C ontro l

R isk Identifica tion

R isk A na lysis

R isk E xposure

R isk R eduction

C ontingency P lann ing

R isk M on ito ring

C ontinuous R eassessm ent

R isk P rio ritiza tion

NEXT PREVIOUS


(Cost, Expectation and Technical)

(What we will lose if the risk occur)

(properly investigating the risk, also looking at the likelihood of occurrence and its impact)

MAIN MENU

NEXT PREVIOUS


RISK REDUCTION

• Avoiding Risk– Modifying project

requirements• Transferring the Risk

– By allocation to other systems

– Buying Insurance to cover financial loses

• Mitigating the Risk– Pre-Event Actions to:

• Reduce Likelihood of Occurrence and/or

• Minimize Impact

CONTINGENCY PLANNING

• Some risks cannot be reduced

• Plan for risk occurrence• Why?

– Reduces “Crisis” atmosphere

– Reduces chance of mistakes

– Reduces time to correct

MAIN MENU

NEXT PREVIOUS

NEED FOR RISK MANAGEMENTMONITORING AND CONTINUOUS REASSESSMENT

• Periodic Review of Risk Status– Changes in Probabilities or Impacts– Changes in Avoidance/Mitigation/Contingency Plans

• Periodic Review of Project to Identify New Risks

• Implementation of Risk Avoidance or Mitigation Plans

• Keep Management and Customers Informed!!!– Frequent Risk Reviews

MAIN MENU

NEXT PREVIOUS

ASSIGNMENT 3 Due Date: To be discussed.

Arrange yourself in groups of two. At most two groups will present on one of the following Life Cycle Models:

1. Waterfall Approach2. Evolutionary Development including rapid prototyping.3. Fountain Approach4. Formal Transformation5. Re-use oriented approach

Use powerpoint presentation to assist in conveying information. Each group has a maximum of 10 minutes to present.

Evidence of research (at least 2 books and 2 websites) is important. Hence, a bibliography slide is to be included in the presentation.

MAIN MENU

Documents

UNIT 2 MODULE 1 Software and System Development Topic : Software Development Compiled by: Careene McCallum-Rodney