Software Design and Development

System analysis is the process of studying an existing system or business problem to understand how it works, identify its problems and information needs, and determine the requirements for a new or improved system. It includes requirements determination, structuring and alternative selection.

A Gantt chart is a horizontal bar chart used in project management. Tasks are listed on the vertical axis and time on the horizontal axis; each bar shows the start date, duration and finish date of a task. It helps to schedule, track progress and show overlapping tasks.

A feasibility study is a preliminary investigation done early in a project to decide whether the proposed system is practical and worth developing, considering technical, economic, operational, schedule and legal factors. Its result is a recommendation to proceed, modify or drop the project.

A process model is a graphical representation of the processes (activities) in a system, showing how data is transformed as it moves through them. The data flow diagram (DFD) is the most common process model. It shows processes, data flows, data stores and external entities.

A decision table is needed to specify complex decision logic clearly and compactly. It lists all conditions and the actions to take for each combination of conditions in a tabular form, so that no case is missed or contradicted. It is easier to read and verify than long narrative text or nested IF statements, and can be converted directly into program code.

Interaction devices are the hardware devices through which users communicate with a computer system, either to input data or to receive output. Input devices include keyboard, mouse, touch screen, light pen, scanner and microphone. Output devices include monitor, printer and speaker. They are chosen for the user's task and the interface design.

Pilot installation (pilot conversion) is a conversion method in which the new system is first installed and used in one part of the organisation, such as a single branch or department, while the rest continues with the old system. After the pilot succeeds, it is extended to the whole organisation. It reduces risk and allows problems to be corrected early.

System maintenance is the process of changing and modifying an information system after it has been installed and is in operation, in order to correct errors, adapt it to new environments, improve performance or add new features. It is the last phase of the systems development life cycle (SDLC) and usually consumes the largest part of the cost.

A use-case diagram is needed to show, at a high level, what a system does from the user's point of view. It identifies the actors (users or external systems) and the use cases (functions) they perform. It helps to gather and communicate requirements, define the system scope and boundary, and gives developers, analysts and clients a shared understanding.

The heart of the system development approach is the systems development life cycle (SDLC), the series of phases that every information system passes through, which gives a structured framework for building systems. The main phases are:

1. Planning (project identification and selection): decide what to build and whether it is worthwhile.
2. Analysis: study the current system and determine requirements.
3. Design: design the logical and physical system (inputs, outputs, files, databases, interfaces).
4. Implementation: coding, testing, installation and training.
5. Maintenance: support, repair and enhance the system.

The life cycle ensures planned, controlled development with documentation and user involvement at each phase.

Project management is the process of planning, executing, controlling and closing a project to meet its objectives. The main activities are:

• Project initiation: defining the scope, objectives and assessing feasibility; forming the team.
• Project planning: estimating tasks, time, cost and resources, scheduling with Gantt/PERT charts, and risk planning.
• Project execution: carrying out the plan, directing the team, and communicating with stakeholders.
• Project monitoring and control: tracking progress against the plan, managing changes, controlling cost, quality and risks.
• Project closure: completing the work, handing over the system, documenting lessons learned and releasing resources.

Project identification and selection is the first phase of the SDLC (planning). It has two parts.

Identification: Needs for new or improved systems are found from sources such as management, department heads, users, the IT department, problems in the existing system, new technology and competitors. Each request is described and recorded.

Selection and classification: The requests are evaluated and ranked using criteria such as:

• value to the organisation and strategic alignment,
• benefits versus costs (economic feasibility),
• technical and operational feasibility,
• resource availability and risk,
• urgency.

The organisation then selects the projects with the highest overall value, and a baseline project plan is prepared for each selected project.

Why draw a DFD. A data flow diagram shows graphically how data moves through a system: its processes, data stores, data flows and external entities. It is drawn because it:

• gives a clear, easily understood picture of the system for both users and developers,
• helps in finding requirements and missing or redundant processes,
• documents the system and supports communication between analyst and user,
• allows the system to be broken down level by level (top-down).

Context diagram. A context diagram is the top level (level 0) DFD. It shows the whole system as a single process, with the external entities that interact with it and the main data flows between them. It defines the system boundary and scope and has no data stores.

Physical file and database design converts the logical data model into the technical specifications used to store and retrieve data on secondary storage.

Main activities:

• Choosing data types, sizes and formats for each field, and coding and compression methods.
• Grouping fields into records and tables (denormalising where needed for performance).
• Selecting file organisation (sequential, indexed, hashed) and access methods.
• Defining primary keys, indexes and other structures to speed up access.
• Deciding on storage media, capacity, backup and recovery, and security.

The goals are efficient use of storage space, fast data processing speed and data integrity and security. The result is the physical schema and file specification that programmers use to implement the database.

Systems maintenance is carried out in a structured process:

1. Obtain a maintenance request: a user or the IT department submits a request describing an error or a change.
2. Analyse and approve the request: the change is studied for its importance, cost and effort, then approved and prioritised.
3. Design the change: the required modification to programs, data and documents is planned.
4. Implement the change: coding is done, followed by testing (unit, system and regression tests).
5. Release and document: the changed system is installed, users are trained, and documentation and version records are updated.

Types of maintenance conducted are corrective (fix errors), adaptive (new environments), perfective (improve performance or features) and preventive (avoid future problems). A configuration management and change control process keeps the changes organised.

Prototyping is a systems development approach in which a small working model of the system is built quickly, shown to users, and refined repeatedly according to their feedback until it meets their needs. It is used when requirements are unclear.

Diagram

 Identify basic requirements
            |
            v
 Develop initial prototype  <------+
            |                      |
            v                      |
 Users use and evaluate prototype  |
            |                      |
   needs revision? --- yes --- Revise prototype
            | no
            v
 Complete / implement and maintain the system

Steps

1. Identify the basic requirements (input, output, key features).
2. Develop a working prototype quickly.
3. Users use the prototype and give feedback.
4. Revise and enhance the prototype; repeat steps 3 and 4 until the users are satisfied.
5. Convert it into the final system (or discard it and build the full system) and maintain it.

Advantages: early user involvement, reduced misunderstanding of requirements, quick visible results, easy to change. Disadvantages: can lead to poor documentation, endless revisions, and incomplete analysis; the prototype can be mistaken for the final system.

A feasibility study checks whether a proposed system is practical. The main types of feasibility tests are:

1. Technical feasibility: Is the required technology (hardware, software, network) available, and does the team have the skills to build and operate the system?
2. Economic feasibility: Do the benefits exceed the costs? Cost-benefit analysis, payback period, return on investment and net present value are used.
3. Operational feasibility: Will the system work in the organisation and be accepted by the users and management? It considers user support and fit with business procedures.
4. Schedule feasibility: Can the system be completed within the available time and deadlines?
5. Legal (and contractual) feasibility: Does the system comply with laws, regulations, licensing and contracts?
6. Political feasibility: Will the key stakeholders in the organisation support the system?

The study ends with a feasibility report recommending whether to proceed.

Entities and attributes

• STUDENT: Student_ID (PK), Name, Address, Phone, Email, Program
• FACULTY: Faculty_ID (PK), Name, Department, Phone, Qualification
• COURSE: Course_Code (PK), Title, Credit_Hours, Semester

Relationships

• STUDENT enrolls in COURSE: many-to-many (M:N). A student takes many courses and a course has many students. Relationship attributes: Enroll_Date, Grade.
• FACULTY teaches COURSE: one-to-many (1:N) in the simple case (one faculty may teach many courses; each course is taught by one faculty in a given term).
• FACULTY advises STUDENT: one-to-many (1:N), optional.

ER diagram (Chen notation, text form)

 [STUDENT]--(Student_ID, Name, Address, Phone, Email)
     |
     M
  <Enrolls in>--(Enroll_Date, Grade)
     |
     N
 [COURSE]--(Course_Code, Title, Credit_Hours, Semester)
     N
     |
  <Teaches>
     |
     1
 [FACULTY]--(Faculty_ID, Name, Department, Phone)

Rectangles are entities, diamonds are relationships, ovals are attributes, and the underlined attributes (Student_ID, Faculty_ID, Course_Code) are primary keys.

Relational mapping

• Student(Student_ID, Name, Address, Phone, Email)
• Faculty(Faculty_ID, Name, Department, Phone)
• Course(Course_Code, Title, Credit_Hours, Semester, Faculty_ID FK)
• Enrollment(Student_ID FK, Course_Code FK, Enroll_Date, Grade), with primary key (Student_ID, Course_Code)

Forms and reports are the main means of input and output in an information system. Formatting them well makes data entry accurate and output easy to read.

Formatting forms (input)

1. Identify the purpose and users: decide what data is captured, who fills it in and from what source document.
2. Layout and flow: arrange fields in a logical sequence (top to bottom, left to right), group related fields, and match the order of the source document.
3. Field design: give clear labels, fixed field lengths, proper data types, default values, and mandatory marks.
4. Controls and validation: use drop-down lists, check boxes, radio buttons, date pickers, format masks, range and type checks to reduce errors.
5. Navigation and help: tab order, prompts, error messages, and a clear Save/Submit/Cancel option.
6. Consistency and appearance: uniform fonts, colours, alignment and white space across all forms.
7. Testing: let users try the form and revise it from their feedback.

Formatting reports (output)

1. Determine the purpose, audience and frequency (detail, summary or exception report).
2. Report header: title, date, page number, organisation name.
3. Body layout: column headings, aligned numbers (right) and text (left), meaningful sorting, grouping, sub-totals and grand totals.
4. Footer: page totals, notes, and end-of-report marker.
5. Readability: appropriate fonts, spacing, limited use of colour, charts or graphs for trends.
6. Medium: choose screen, print or export (PDF/Excel) and set margins and orientation accordingly.
7. Review: prototype the report, get user approval, and then finalise.

Good formatting makes forms and reports accurate, consistent, readable and easy to use.

External entities: Customer, Restaurant/Kitchen Staff, Delivery Person, Payment Gateway, Admin.

Context diagram (Level 0)

The whole system is one process, 0 Online Food Ordering System, with these flows:

Customer ----registration details, order, payment info----> [0 Online Food Ordering System]
Customer <---menu, order confirmation, bill, status-------- [0 ...]
Restaurant <--order details----------------------------- [0 ...]
Restaurant ---order accepted/ready, menu updates---------> [0 ...]
Delivery Person <--delivery details--------------------- [0 ...]
Delivery Person ---delivery status----------------------> [0 ...]
Payment Gateway <--payment request---------------------- [0 ...]
Payment Gateway ---payment confirmation-----------------> [0 ...]
Admin ---food items, prices, user management------------> [0 ...]
Admin <--sales reports----------------------------------- [0 ...]

Level 1 DFD

Processes:

1. Manage Customer Account: customer registration/login. Uses D1 Customer.
2. Browse Menu and Place Order: reads D2 Food Items, creates order in D3 Orders.
3. Process Payment: sends payment request to the gateway, gets confirmation, updates D4 Payments.
4. Prepare and Deliver Order: sends order to Restaurant, assigns Delivery Person, updates order status in D3.
5. Generate Reports and Manage Items: Admin maintains D2, and reads D3/D4 to produce sales reports.

Data stores: D1 Customer, D2 Food Items, D3 Orders, D4 Payments.

Flow: Customer -> (1) -> D1; Customer -> (2) <- D2; (2) -> D3; (2) -> (3) <-> Payment Gateway; (3) -> D4; (3) -> (4); (4) -> Restaurant, Delivery Person; (4) -> D3; (4) -> Customer (status); Admin -> (5) <- D2, D3, D4; (5) -> Admin (reports).

Level 2 DFD (of process 2, Browse Menu and Place Order)

• 2.1 View Menu: reads D2 Food Items, returns the menu to Customer.
• 2.2 Select Items / Manage Cart: Customer sends selected items and quantity; the process checks availability against D2 and totals the price.
• 2.3 Confirm Order: Customer gives delivery address and confirms; the order is stored in D3 Orders and passed to process 3 (Process Payment), and an order confirmation is returned to Customer.

Level 2 of process 3 (Process Payment) can similarly be split into 3.1 Select Payment Method, 3.2 Verify Payment with Gateway, 3.3 Generate Bill/Receipt (stored in D4).

Each process is numbered, every data store is read or written, and the inputs and outputs of each level balance with the level above.

Agile development

Agile is an iterative and incremental approach to software development in which the software is built in short cycles (iterations or sprints, usually 1 to 4 weeks). Each cycle delivers a working increment, and requirements and solutions evolve through close collaboration with the customer. It is based on the Agile Manifesto (2001), which values:

• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to change over following a plan

Process: requirements (user stories) -> planning -> design -> coding -> testing -> review with customer -> release, repeated each iteration.

Characteristics: short iterations, continuous customer feedback, welcome to changing requirements, self-organising cross-functional teams, daily stand-up meetings, continuous integration and testing, and simplicity.

Methods: Scrum (roles: Product Owner, Scrum Master, Team; artefacts: product backlog, sprint backlog; events: sprint planning, daily scrum, sprint review, retrospective), Extreme Programming (pair programming, TDD, refactoring), Kanban, and Feature Driven Development.

Advantages: early and frequent delivery, flexibility to change, better customer satisfaction, early defect detection, and better risk control.

Disadvantages: weak documentation, difficult to estimate cost and time, needs an experienced and committed team and customer involvement, and scope can creep.

Class diagram

A class diagram is a UML structural diagram showing classes, their attributes and operations, and the relationships among them. A class is drawn as a rectangle with three compartments: name, attributes, operations. Visibility: + public, - private, # protected.

Relationships: association (a line with multiplicity such as 1..*), aggregation (hollow diamond), composition (filled diamond), generalisation/inheritance (hollow triangle arrow), and dependency (dashed arrow).

Example (college system):

+---------------------+          +----------------------+
| Student             |  *    1..* | Course               |
|---------------------|----------|----------------------|
| -studentId: int     | enrolls  | -code: String        |
| -name: String       |          | -title: String       |
|---------------------|          |----------------------|
| +register()         |          | +addStudent()        |
| +getGrade()         |          | +getCredits()        |
+---------------------+          +----------------------+
         ^                                  |  *
         |  (inheritance)                   | taught by
+---------------------+                     | 1
| GraduateStudent     |           +----------------------+
|---------------------|           | Teacher              |
| -thesisTitle:String |           | -teacherId, -name    |
+---------------------+           | +teach()             |
                                  +----------------------+

Here Student and Course have a many-to-many association, Teacher teaches many Courses (one-to-many), and GraduateStudent inherits from Student. Class diagrams are used to model the static structure of the system and as the basis for code generation.