Software Engineering 2068

A software process is a set of related activities that leads to the production of the software. These activities may involve the development of the software from the scratch, or, modifying an existing system.

Any software process must include the following four activities:

1. Software specification (or requirements engineering): Define the main functionalities of the software and the constrains around them.

2. Software design and implementation: The software is to be designed and programmed.

3. Software verification and validation: The software must conforms to it’s specification and meets the customer needs.

4. Software evolution (software maintenance): The software is being modified to meet customer and market requirements changes.

A software process model is the abstract representation of a software process. It is a structure of a software process present the description of a process. Each process model represents a process from a particular perspective.

Examples of process perspectives:

• Workflow perspective represents inputs, outputs and dependencies.
• Data-flow perspective represents data transformation activities.
• Role/action perspective represents the role/activities of the people involved in software process.

There are several process models are available

1.      Waterfall model

2.      Generic process model

3.      Incremental model

4.      Agile process model

5.      Prototyping model

6.      Spiral model

7.      Iterative development model, etc.

Software engineering is an engineering discipline that is concerned with all aspects of software production. Software engineering focus on cost effective development of high-quality software system. The result of software engineering is an effective and reliable software product.

Software engineering focus on the following challenges:

i. Heterogeneity Challenge:  Every organization is required to operate as a distributed system across the network that includes different types of computer and with different types of supporting system. The heterogeneity challenge is the challenge of developing software that is flexible enough to cope with heterogeneous system.

ii. Delivery Challenge: Traditional software engineering techniques are time consuming. The time they take is required to achieve software quality. However, business organization today must be responsive and change very rapidly. Their supporting software must change equally. The delivery challenge is the challenge to provide the software within short time without compromising software quality.

iii. Trust Challenge: Trust challenge is to develop a technique that demonstrates that software can be trusted by its user.

Systems design is the process of defining elements of a system like modules, architecture, components and their interfaces and data for a system based on the specified requirements. It is the process of defining, developing and designing systems which satisfies the specific needs and requirements of a business or organization.

System design process:

1. Architectural design, the sub system making the system and their relationship are identified.

2. Abstract specification, for each sub system, an abstract specification of its services and constraints is produced.

3. Interface design, for each sub system, its interfaces with others is designed.

4. Component design: services are allocated to the component and the interfaces for this component is designed.

5. Data structure design: the data structure used in this system are designed in detail.

6. algorithm design: the algorithm used in this system are designed in detail.

When a system is produced using the evolutionary development model, features tend to be added without regard to an overriding design. With each modification, the software becomes increasingly disorganized. System maintenance hampered by these problems, as it is harder identify the source of bugs in poorly designed systems. Also, keeping the documentation up to date over successive "evolution" is uncommon. Poor documentation also makes maintenance more difficult.

• It leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the full system was designed.
• there results incomplete or inadequate problem analysis.

• A milestone is a scheduled event signifying the completion of a major deliverable or a set of related deliverables. A milestone has zero duration and no effort -- there is no work associated with a milestone. It is a flag in the work plan to signify some other work has completed.
• Usually a milestone is used as a project checkpoint to validate how the project is progressing and revalidate work. Milestones are also used as high-level snapshots for management to validate the progress of the project. In many cases there is a decision to be made at a milestone.
• Deliverable is a term used in project management to describe a tangible or intangible object produced as a result of the project that is intended to be delivered to a customer (either internal or external). A deliverable could be a report, a document, a server upgrade or any other building block of an overall project. The word is considered corporate jargon.
• A deliverable may be composed of multiple smaller deliverables. It may be either an outcome to be achieved or a product to be provided

The major difference between a milestone and a deliverable is that a milestone signifies project progress towards obtaining its end objectives, a stepping stone that must be reached in order to continue, whereas a deliverable is a measurable result of this process.

Requirements elicitation and analysis is a process of interacting with customers and end-users to find out about the domain requirements, what services the system should provide, and the other constrains.

The requirements elicitation and analysis has 4 main process:

The users, customers or other stakeholders involved in the software development do not know all the features and behavior they need to have in the software at the time of requirements gathering. End-users at first encounter are most likely to give unrealistic requirements or requirements that are filled with ambiguities. The term elicitation is a pointer to the fact that good requirements cannot be obtained simply by asking the user, customer or stakeholders what they want. Requirements elicitation therefore calls for multiple interviews, questionnaires, user observations, brainstorming sessions and lots of prototypes. This is why requirements elicitation is difficult.

Rapid prototyping involves creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The model then becomes the starting point from which user can re-examine their expectations and clarify their requirements. When this goal has been achieved, the prototype model is thrown away and the system is formally developed based on the identified requirements.

Rapid prototyping techniques

Various techniques may be used for rapid development:

1. Using high level language:

• High level language include many powerful data management facilities. 
• Using high level language we can create prototype with very little programming effort.
• Some languages offer excellent UI development facilities.

2. Reuse component:

The time need to develop a prototype can be reduced if many parts of the systems can be reused rather than designed and implemented. The reusable components may also be used in the final system thus reducing its development cost.

3. Ignore error handling:

In many system as much as one-half of the software is concerned with error handling. The time need to develop a prototype can be reduced If we ignore the error while designing prototype.

4. Omit features:

Omit features which are costly and takes large time to develop. So their omission make construct of prototype quicker.

5.Ignore functionality:

Only focus on establishing an acceptable user-interface.

6. Database programming language:

It includes a database query language, a screen generator, a report generator and a spreadsheet. These may be integrated with a CASE toolset. These are cost effective for small to medium sized business system.

A formal software specification is a statement expressed in a language whose vocabulary, syntax, and semantics are formally defined. It is a technique for unambiguous specification of software to be build. The specification languages cannot be based on natural language; it must be based on mathematics because natural language specification are informal and usually contain ambiguities.

Fig: Formal specification in software process

The system requirements and system design are expressed in details and carefully analyzed and checked before implementation begins. A formal specification of software is developed after the system requirement have been specified but before the detailed system design.

The main benefit of formal specification is its ability to uncover problem and ambiguities in the requirements specification. It forces to system analysis to remove errors and inconsistencies in the requirement specification.

Two fundamental techniques for formal specification are:

1. Algebraic Approach: In algebraic approach, system is described in terms operation and their relationship. It consists of two parts: signature, which determines syntax of operation and an equation, which defines the semantics of operations.

2. Model-Based Approach: In model based approach, the abstract model of system is built using mathematical construct such as set theory, function theory and logic. It specifies the operations performed on abstract model.

Control models are models deployed in software engineering that are concerned with the control flow between the subsystems. They are distinct from the system decomposition model. There are two types of control models: centralized and event-based control model.

Centralized Control Model

Centralized model is a formulation of centralized control in which one subsystem has overall responsibility for control and starts and stops other subsystems. It is a control subsystem that takes responsibility for managing the execution of other subsystems. Centralized models are classified into call-return and manager model.

1. Call-return Model: In call-return model, it is a model which has top-down subroutine architecture where control starts at the top of a subroutine hierarchy and moves downwards.

The call-return model is illustrated in above figure. The main program can call Routines 1, 2 and 3; Routine 1 can call Routines 1.2 or 1.2; Routine 3 can call Routines 3.1 or 3.2; and so on.

2.  Manager Model: Manager model is applicable to concurrent systems. One system component controls the stopping, starting and coordination of other system processes.

Event-based Control Model

Event-based models are those in which each sub-system can respond to externally generated events from other subsystems or the system’s environment. It is a system driven by externally generated events where the timing of the events is out with the control of the subsystems which process the event.

Event-based models are classified into broadcast and interrupt-driven models.

1. Broadcast models: In these models, an event is, in principle, broadcast to all sub-systems. Any sub-system, which is designed to handle that event, responds to it.

2. Interrupt-driven models: These are exclusively used in real-time systems where an interrupt handler detects external interrupts. They are then passed to some other component for processing.

A Use Case consists of use cases, persons, or various things that are invoking the features called as actors and the elements that are responsible for implementing the use cases. The purpose of use case diagram is to capture the dynamic aspect of a system.

Use Case Diagram captures the system's functionality and requirements by using actors and use cases. Use Cases model the services, tasks, function that a system needs to perform. Use cases represent high-level functionalities and how a user will handle the system. 

Use case diagram consists of 4 objects:

1. System: System is used to define scope of the use case and drawn as a  rectangle.

2. Use Case: It represents the function or an action within the system. It is drawn as an oval and name with the function.

3. Actors: Actors are the users of a system. They interact with the system being designed in order to obtain some value from that interaction.

Relationships: Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.

Verification is the process of evaluating the product during the development to find out whether they meet the specific requirements (functional and non-functional requirements).

Validation is the process of checking the product after development to determine whether software meets the customer expectations and requirements.

The ultimate goal of verification and validation process is to establish confidence that the software system is "fit for purpose".

Verification and Validation planning

Validation and verification  is an expensive process and more than the half the system development budget may be spend on validation and verification process. So, careful planning is needed for validation and verification (V & V).

Fig: Test plans as a link between development and testing

It breaks down system V & V into a number of stages. Each stage is driven by tests that have been defined to check the conformance of the program with its design and specification.

We should decide on the balance between static and dynamic approaches to V & V, draw up standards and procedures for software inspections and testing, establish checklists to drive program Inspections and define the software test plan. 

Test planning is concerned with establishing standards for the testing process. It helps managers to allocate resources and estimate testing schedules, test plans are intended for software engineers involved in designing and carrying out system tests. It helps technical staff get an overall picture of the system tests and place their own work in this context.

a. Data Flow Models

A data flow model is diagramatic representation of the flow and exchange of information within a system. Data flow models are used to graphically represent the flow of data in an information system by describing the processes involved in transferring data from input to file storage and reports generation. A data flow model may also be known as a data flow diagram (DFD).

Data flow modeling can be used to identify a variety of different things, such as:

• Information that is received from or sent to other individuals, organizations, or other computer systems.
• Areas within a system where information is stored and the flows of information within the system are being modeled.
• The processes of a system that act upon information received and produce the resulting outputs.

b. COCOMO model

The COCOMO (Constructive Cost Model) is one of the most popularly used software cost estimation models i.e. it estimates or predicts the effort required for the project, total project cost and scheduled time for the project. This model depends on the number of lines of code for software product development. COCOMO model has three types:

1. The Basic COCOMO

2. The Intermediate COCOMO

3. The Detailed COCOMO

c. Security assessment

Security assessment is a measurement of the security posture of a system or organization. The security posture is the way information security is implemented. Security assessments are risk-based assessments, due to their focus on vulnerabilities and impact.

The assessment of system security is increasingly important as more and more critical systems are Internet-enabled and so can be accessed by anyone with a network connection. There are daily stories of attacks on web-based systems, and viruses and worms are regularly distributed using Internet protocols. The verification and validation processes for web-based systems must focus on security assessment, where the ability of the system to resist different types of attack is tested.