0% found this document useful (0 votes)
3 views4 pages

Initial Design Model in SDLC

Chapter 4 discusses the process of building an initial design model in the Software Development Life Cycle (SDLC), emphasizing the importance of prioritizing requirements and generating alternative design strategies. It outlines the criteria for selecting implementation environments, including outsourcing options, software sources, and hardware considerations. Additionally, it reviews the relational database model, highlighting the characteristics of well-structured relations and the significance of primary keys.

Uploaded by

yalewastatikie3
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views4 pages

Initial Design Model in SDLC

Chapter 4 discusses the process of building an initial design model in the Software Development Life Cycle (SDLC), emphasizing the importance of prioritizing requirements and generating alternative design strategies. It outlines the criteria for selecting implementation environments, including outsourcing options, software sources, and hardware considerations. Additionally, it reviews the relational database model, highlighting the characteristics of well-structured relations and the significance of primary keys.

Uploaded by

yalewastatikie3
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Chapter 4

1 Building the Initial Design Model


 provides a starting point for the next phase in the SDLC, that of Design.
 To build the initial design model the analyst must select the best design strategy for the system.
This involves:
 Prioritising the requirements into different sets of capabilities –
from the minimum set of requirements that users will accept – the mandatory requirements –
up to the full range of capabilities that a fully functional system should have.
 Listing different implementation environments –different types of hardware, software and network
platforms that could be used to implement the different sets of capabilities.
 Looking at different ways to develop the various sets of capabilities for the different implementation
environments.
The options include
in-house development
purchasing off-the-shelf software
contracting development out to an outside supplier.

Sets of Capabilities
to generate alternatives design strategies, first rank or prioritize the requirements for the new system. This ranking
must be agreed by all involved – end users, management, and analysts.
 The ranking often rates each requirement as one of the following:
 Mandatory – these are 'must-have' capabilities that must be in the system, otherwise the users will not
accept it. This set can be used to filter out some possible alternatives.
 Essential – capabilities that are important and
--can be used to compare different design strategies.
 Desired – these are 'nice-to-have' capabilities that do not have to be in the system, but which users could do
without.

1.1 Generating Alternatives


When generating the alternative design strategies, a good number to generate is three. These are usually as follows:
 a low-end alternative
 a mid-range alternative
 a high-end alternative.

The low-end alternative:


 Most conservative in terms of the cost, effort and technology involved in developing the new
system.
 Sometimes this can mean that the solution does not involve any computer-based development
at all
 e.g. just improvements to the flow of paper in a system.
 This alternative covers the mandatory capabilities of the system.
The high-end alternative: focuses on functionality.
 It will solve the problem and also include extra desired features – as well as the mandatory and
essential features.
 It will be designed using advanced technology that can be expanded to allow for future
requirements.
The mid-range alternative: is in between the low-end and high-end.
 It is a compromise solution that attempts to balance cost and functionality.

1
Chapter 4

1.2 Issues to Consider when generating alternatives


Issues that should be considered when generating the alternative design strategies.
 Outsourcing
 Sources of Software
 Choosing Off-the-Shelf Software
 Hardware and System Software Issues
 Implementation & Operation Issues

1.2.1 Outsourcing
occurs when an organization gives responsibility for developing and running some or all of the organization's
Information System applications and operations to an outside firm.
There are different types of arrangement for outsourcing. The most common are:
 Your application is run on the outsourcing firm's computers; you supply the input and received the output.
For example, this is often used for payroll systems.
 Your application is run on your computers, but run by staff from the outsourcing company. In this case,
there are often no internal IS/IT staff.

1.2.2 Sources of Software


There are various types of company that can be sources of application software for systems. These can be considered
when looking for possible sources of software to buy off-the-shelf for a new system. These are as follows.
 Hardware manufacturers: many of the leading hardware manufacturers also make software
: E.g. IBM makes operating systems and DBMS software
 Packaged software producers: companies such as Microsoft and Oracle are software companies that
produce off-the-shelf or pre-packaged software applications.
 Custom software producers: if an organization needs an information system but does not have the
necessary expertise or enough staff to develop it in-house, a custom software company can be consulted.
-----There are many consulting firms, ranging in size from small local companies to large multi-nationals
Who do this.
 Enterprise solution software:
-- An enterprise solution: is a system that integrates individual business functions into a series of modules
so that a single transaction occurs seamlessly in a single Information System, rather than in several
different systems.
-- All parts of a business process are integrated into a unified business system.
 In-house development: the above 4 options are external. The possibility of developing the new system
internally is also an option. Some or all of the system may be built in-house.

1.2.3 Criteria for Choosing off-the-shelf Software


If the organization and/or analyst chooses to purchase off-the-shelf software rather than writing all of it in-house, the
following criteria should be considered when buying software:
 Cost – should be compared to that of in-house development; the cost of licences, first-time purchase and
future upgrades should be considered.
 Functionality – does the software meet some or all of the capabilities? Does it meet the minimum set of
capabilities?
 Vendor Support – does the supplier of the software provide support for problems and for installation? Do
they provide staff training? And how much does this cost?
 Vendor Viability – is the vendor doing well in business, will they still be in business next week, next
year…?
 Flexibility – can the software be modified, is it customisable?
 Documentation – do they provide a user manual, technical documentation? What is the cost for multiple
copies of these?
 Response Time – what is the software's response time when a user requests information from it?
 Ease of Installation – how easy or difficult is to load the software and make it operational?
The software should also be tested, on the organization's own PCs, not just on those of the vendor.

2
Chapter 4

1.2.4 Hardware and System Software Issues


The hardware and system software should be looked at
 to determine if a particular design strategy can be run on the organization's existing hardware and software
platform.
 all the applications in an organization run on the same platform, and this is more cost-effective than
maintaining two or more different platforms.
This also allows for compatibility between applications and systems.
Hardware : actual computers and peripherals used e.g. servers, client PCs, printers, backup tape machines etc.
System software : includes key components such as operating systems, database management systems (DBMS),
programming languages.
 The following should be considered when determining if the existing platform is sufficient for a particular
design strategy:
 the age and capacity of the existing systems
 does it fit with the new application's goals and functionality
 If some of the new system components will be off-the-shelf software, can the software run on the existing
platform?
There are benefits to running the new system on the existing platform, and there are also some benefits to acquiring
a new platform.
Benefits of running on existing platform:
 Lower cost – little or no new hardware/system software to be purchased
 IS staff are familiar with the existing platform – they know how to operate and maintain it
 Easier to integrate new applications with existing applications
 No need to convert old systems to a new platform or to translate data between current technology and new
technology
Benefits of acquiring a new platform:
 Provides an opportunity to upgrade or expand current technology in the organization
 It may be a chance to make a radical change to the organization's information systems.

1.2.5 Implementation & Operation Issues


 Involves technical issues but also issues related to people and processes.
When a new system is implemented,
staff may have to adjust to new work processes, new working relationships and the gaining of new skills.
Training needs must be considered – when and how to deliver training, for example.
The implementation may involve disruption to daily business operations.
The implementation may need to take place over a long time period of weeks or even months.

2 Review of the Relational Database Model


 In a relational database, data is represented in tables or relations.
 A relation has a name and consists of a set of named columns and a variable number of rows.
 Each column in a relation corresponds to an attribute of that relation.
 Each row of a relation corresponds to a record that contains data values for an entity.
Consider, for example, a relation named EMPLOYEE that has attributes EmpID, Name, Department, Salary, with 5
sample rows in the table.
EMPLOYEE
Name Department Salary
Emp_ID
100 Sara Negash Information Technology 100000
101 Andy King Administration 100000
102 Terri O'Sullivan Finance 90000
103 Tekle Haimanot Information Technology 88000
105 Terhas GebreSelassie Marketing 120000
Figure 1 – EMPLOYEE relation with sample data
 the identifier attribute is underlined and is also called the primary key of the relation:
Employee ( EmpID, Name, Department, Salary)

3
Chapter 4

 A primary key is an attribute (or combination of attributes) that is unique for all rows in the relation.
Not all database tables are relations.
The properties of a relational table that distinguish it from non-relational tables are:
 Entries in cells of the table are simple i.e. an entry at the intersection of a row and a column has a single
value – this concept is called atomicity
 Entries in a given column are from the same set of values – this set is called a domain or data type. The
values in a column also have rules of behaviour based on the domain or data type: number, variables....
 Each row is unique. The uniqueness is guaranteed because each row has a non-empty primary key value.
 The sequence of the columns in a relation can be changed without changing the meaning or use of the
relation.
 The rows in a relation can be interchanged or stored in any sequence.

When designing a database, the analyst should aim to design well-structured relations/tables.
 A well-structured relation:
Contains a minimum amount of redundancy and
Allows users to insert, update and delete the rows in a table without errors or inconsistencies.

You might also like