068 SE

old question solution

Difference between software process and software process model

Software Process:- It is a set of activities and associated results that produce a software product. These activities may involve the development of the software from the scratch, or, modifying an existing system. It is a method of developing software. It is complex and relies on making decisions. There’s no ideal process and most organizations have developed their own software process.

Software Process Model:- It is a simplified representation of a software process, presented from a specific perspective. Software process model may include activities that are part of the software process, software products and the role of people involved in software engineering. Software process models are abstractions of the process that can be used to explain different approaches to the software development Less complex and doesn’t relies on making decisions. There is some specific software process models.

Key Challenges facing in Software Engineering

The Heterogeneity challenge:- Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and with different kinds of support systems. The heterogeneity challenge is the challenge of developing techniques to build dependable software which is flexible enough to cope with this heterogeneity.

The delivery challenge:- Many traditional software engineering techniques are time-consuming. The time they take is required to achieve software quality. However, businesses today must be responsive and change very rapidly. Their supporting software must change equally rapidly. The delivery challenge is the challenge of shortening delivery times for large and complex systems without compromising system quality.

The legacy challenge:- The majority of software systems which are in use today were developed many years ago yet they perform critical business functions. The legacy challenge is the challenge of maintaining and updating this software in such a way that excessive costs are avoided and essential business services continue to be delivered.

The trust challenge:- As software is intertwined with all aspects of our lives, it is essential that we can trust that software. This is especially true for remote software systems accessed through a web page or web service interface. The trust challenge is to develop techniques that demonstrate that software can be trusted by its users.

System Design

System design is concerned with how the system functionality is to be provided by the system component. The system design phase involves the following activities:

i. Partitioning requirement:- Analyze the requirement and organize them into related groups.

ii. Identify Subsystem:- In this activity, the subsystem should identify that can individually and collectively meet the requirement. Groups of requirements are usually related to subsystem.

iii. Assign Requirement to Subsystem:- The related groups of requirements are assigned to the subsystem.

iv. Specify Subsystem Functionality:- The specific function provided by each subsystem is specified. The relationship between subsystems is also identified at this activity.

v. Define Subsystem Interface:- Define the interface that are provided and required by each subsystem. Once these interface have been agreed, then it become possible to develop subsystem in parallel.

There is a lot of feedback and iteration from one activity to another activity in this phase. This process ends when the review and evaluation show that the requirement and high level design are sufficiently detailed to allow the next phase of system design.

Why program are developed using evolutionary development are likely to be difficult to maintain?

The specifications of evolutionary development projects are often abstract,and as the project continues, the development and validation portions of software engineering overlap one another. This usually results in the systems being poorly constructed due to a good initial specification, and on large projects make it more difficult to integrate new systems into the evolutionary design. Lastly, the documentation for such projects is often lacking, as the designs are constantly rebuilt to the customer’s specification.

What is the critical distinction between a milestone and deliverable ?

A deliverable is a measurable and tangible outcome of the project. They are developed by project team members in alignment with the goals of the project. Deliverables are the project result which is delivered to the clients. They are delivered at the end of project phases, such as design and implementation. Acceptance of deliverables can represent a certain milestone. Deliverables are the consequences of the work carried out during the phase.

Milestones on the other hand are checkpoints throughout the life of the project. They identify when one or multiple groups of activities have been completed thus implying that a notable point has been reached in the project. Milestones are set for the project managers and project team to ensure project progress. They are not delivered to the clients. Milestones refer to significant events or achievements, which involves deliverables presented. Milestones are to ensure the project team focus on the current phase or work.

A project usually has more deliverables than milestones.

Why requirement elicitation and analysis is a difficult process in software engineering ?

Activities in Requirement Elicitation and Analysis:

i. Requirement Discovery:- In this phase requirements are collected from stockholder. The requirement should match the system .

ii. Requirement Classification and Organization:- This activity takes the unstructured collection of requirements, group of related requirement and organizes them into a proper structured manner.

iii. Requirement Prioritizing:- Where multiple users are involved, requirement will be conflict .This activity is concerned with prioritizing requirement, finding and resolving requirement conflicting with discussing stakeholders.

iv. Requirement Documentation:- The requirement is documented in a proper sequence which is input to the next stage of requirement engineering process.

Rapid prototyping techniques

Rapid Prototyping is the “process of quickly building and evaluating a series of prototypes” early and often throughout the design process. Prototypes are usually incomplete examples of what a final product may look like. Each time a prototype is used, a formative evaluation gathers information for the next, revised prototype. This cycle continues to refine the product until the final needs and objectives are met. The following diagram demonstrates the non-linear nature of Rapid Prototyping.

Rapid prototyping techniques

1. Materials — The tools used for rapid prototyping of non-product applications are usually chosen for flexibility and affordability as well as ease of use. This is critical to keeping the initial design and redesign costs as low as possible.

• Paper and Pen — Almost everyone has access to these and understands how to use them
• Mock-up Software — This can be very inexpensive and requires some knowledge, but it is optimal for multiple redesigns.
• Whatever’s around — Create 3D or special representations of design components

2) Sample prototypes –

• Paper Mock-ups
• Storyboards
• Simple physical models
• Role Playing Scenarios
• Idea Cards

3) Session — The process can be self organized by a team of designers, or it can be facilitated. If the design team does not include customers/end users, a way to gather feedback on the prototypes from users will be required.

4) Record — A way to document feedback and ideas is beneficial but not necessary. In some cases, feedback will immediately be captured in a modification or a new, rough prototype during the session, so extensive documentation may not be necessary.

5) Analysis — Feedback and micro failures during rough prototyping inform direction and refinement, which can move the process into the Pilot phase.

Formal Specification

It is a techniques for the unambiguous specification of software. It helps to discover problems of in system requirement. A formal specification of s/w is developed after the system requirement have been specified but before the detailed system designed.

Two fundamental approaches for formal specification have been used to write detail specification for s/w system.

1. Algebraic Approach:
   In algebraic approach system is described in terms of operation and their relationship.
2. Model Based Approach:
   In model based approach the system is built using mathematical construct such as sets and sequence and the system operation are defined by how they modify the system state.

Control Model and It’s type

A control model deals with control flow between the subsystems. In order to make a system work effectively, its constituent sub systems must be controlled to ensure that the services are delivered in a precise manner. There are two types of control models. They are:
1. Centralized Control Model:- In this model, one of the subsystems is designated as system controller with responsibility for managing the execution of other subsystems. Depending on whether the controller system executes sequentially or in parallel, the centralized controlled models are of two types:
i. Call- return Model:- This is a top- down sub-routine model where the control passes from a higher level subroutine in a hierarchy to the lower level routine. This model is only applicable to sequential system. In this model, currently executing subroutine has the responsibility for control. It can either call other subroutines or returns control to its parent.

ii. The manager model:- This is applicable to concurrent systems. One system component is designated as a system manager and controls the starting, stopping, coordination and scheduling of other system processes. A process is a component or module that can execute in parallel with other processes. A form of this model may also be applied in sequential systems where a management routine calls particular components depending on the values of some state variables. This is usually implemented as a case statement.

2. Event -Driven Model:- These models are driven by externally generated events. There are two types of such models which are:

i. Broadcast Model:- These are appropriate for integrating subsystems distributed across different computers on a network. In this model, an event is broadcast to all the subsystems. Any subsystems which can handle that event respond to it. The event and message handler maintain a register of subsystems and the events of interest to them. The event handler detects the event to those subsystems that have registered an interest in the event. A subsystem can send a message to another subsystem.

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

Use Case Diagram

A use case diagram at its simplest is a representation of a user’s interaction with the system that shows the relationship between the user and the different use cases in which the user is involved. A use case diagram can identify the different types of users of a system and the different use cases and will often be accompanied by other types of diagrams as well. The purpose of a use case diagram in UML is to demonstrate the different ways that a user might interact with a system.

Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system.

Verification and Validation planning

In the development life cycle of any software, it must be checked before implementation to ensure if its specification and functionality are fulfilled. Verification and Validation is the name to these checking and analysis. They start with requirement review.

Verification => Are we building product right ??

Validation => Are we building right product ??

Careful planning is required to get the most out of testing and inspection process. Planing should start from early stage of development. Effective V & V plan requires many considerations that are:

1. Identification of V & V Goals
2. Selection of V & V Techniques
3. Organizational Responsibilities
4. Integrating V & V Approaches
5. Problem Tracking

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). A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination.

DFD symbols

DFD example online store

COCOMO Model

Constructive cost model (COCOMO) is one of the best documented algorithmic cost estimation models. This is an empirical model derived after analyzing the data related to 63 completed software projects.

Basic COCOMO Model

The basic COCOMO model gives an approximate estimate of the project parameters. The basic COCOMO estimation model is given by the following expressions:

Effort = a1*(KLOC)a2*PM
Tdev = b1*(effort)b2*months

Where

• KLOC is the estimated size of the software product expressed in Kilo Lines of Code,
• a1, a2, b1, b2 are constants for each category of software products,
• Tdev is the estimated time to develop the software, expressed in months,
• Effort is the total effort required to develop the software product, expressed in person months (PMs).

Security Assessment

The assessment of system security is becoming increasingly important as more and more critical systems are Internet-enabled and can be accessed by anyone with a network connection. This means verification and validation processes for web-enabled system must focus on security assessment. Where the ability of the system to resist different types of attack is tested. However, these types of security assessment are very difficult to carry out. Fundamentally, the reason why security is so difficult to assess is that security requirement, like some safety requirements are shall not requirements. That is they specify what should not happen rather than system functionality or required behavior. It is not usually possible to define this unwanted behavior as simple constraint that may be checked by the system.

There are four complementary approaches to security checking:-

1. Experience-Based Validation
2. Tool-Based Validation
3. Tiger Team
4. Formal Specification