UNIT 2 : SOFTWARE ENGINEERING PRACTICES & SOFTWARE REQUIREMENT ENGINEERING

Topics:

  • Software engineering practice
  • Communication practices
  • Planning practices
  • Analysis modeling practices
  • Design modeling practices
  • Construction practices
  • Deployment practices 

1) List & Explain Seven Core principle(Devid Hooker) of software engineering ?

Ans:

  • The reason that the software exists
    • The software should provide value to its users and satisfy the requirements
  • Keep it simple, stupid (KISS)
    • All design and implementation should be as simple as possible
  • Maintain the vision of the project
    • A clear vision is essential to the project’s success
  • what you produce Others will consume
    • Always specify, design, and implement knowing that someone else will later have to understand and modify what you did
  • Be open to the future
    • Never design yourself into a corner; build software that can be easily changed and adapted
  • Plan ahead for software reuse
    • Reuse of software reduces the long-term cost and increases the value of the program and the reusable components
  • Think, then act
    • Placing clear, complete thought before action will almost always produce better results

2) Explain any THREE Core Principle of software engineering?

Ans:

  • The reason that the software exists :A software system exists for one reason:to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: “Does this add real VALUE to the system?” If the answer is “no”, don’t do it. All other principles support this one.
  • Keep it simple, stupid (KISS): Software design is not a haphazard process. There are many factors to consider in any design effort.All design should be as simple as possible, but no simpler. This facilitates having a more easily understood, and easily maintained system. This is not to say that features, even internal features, should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the more simple ones. Simple also does not mean “quick and dirty.” In fact, it often takes a lot of thought and work over multiple iterations to simplify. The payoff is software that is more maintainable and less error-prone.
  • what you produce Others will consume : seldom is an industrial-strength software system constructed and used in a vacuum. In some way or other, someone else will use, maintain, document, or otherwise depend on being able to understand your system. So, always specify, design, and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern for those that must maintain and extend the system. Someone may have to debug the code you write, and that makes them a user of your code. Making their job easier adds value to the system.
  • Plan ahead for software reuse: New literature is addressing the reuse of design in the form of software patterns. However, this is just part of the battle. Communicating opportunities for reuse to others in the organization is paramount. How can you reuse something that you don’t know exists?Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.

3) List & Explain Communication Principles?

OR

3) Explain any THREE CommunicationPrinciple Statements?

Ans:

  1. Listen
    Prepare before you communicate
    3. Someone should facilitate the activity
    4. face to face communication is best.
    5. Take notes and document decisions
    6. Strive for collaboration
    7. Stay focused, modularize your discussion.
    8. If something is unclear, draw a picture
    9. Once you agree to something move on; If you can’t agree tosomething move on; If a feature or function is unclear and cannot be clarified at the moment, move on.
    10. Negotiation is not a contest or a game. It works best when both parties win.
  1. Listen carefully

i.To collect lots of data from the client, the developer team has to listen carefully.

ii.Maximum information with respect to requirement and the specifications should be collected before the implementation and the designing of the software.

  1. Prepare before you communicate

i.A proper agenda or the guidelines for the meetings should be prepared before the start of the meeting.

ii.Complete detail and the description about the clients and their work area should be gathered to deliver the software up to the best expectation.

  1. Have a facilitator for any communication meeting

i.The requirement gathering and the specification are important for any software development, hence the communication should continue till the requirement gathering is over.

  1. Face-to-face communication is best

i.It is always better to sit across the table and have discussion on the requirement on the software development by the client and the developer.

  1. Take notes and document decisions

i.The important points discussed should also be recorded.

ii.Proper notes and the documentation is important for the successful completion and deployment of the project.

  1. Strive for collaboration

i.Collaboration in terms of teamwork is required for the successful completion of the software.

ii.The collective knowledge of the team members should be implemented in the development.

  1. Stay focused and modularize your discussion

i.As the development is the working of many team members, so the possibility of the discussion going from one topic to the other topic is quite possible.

ii.As a good software developer it is required that the discussion remains focused on the specified area.

  1. Draw a picture if something is unclear

i.Drawing flowcharts, E-R diagrams and other supporting graphical representations give clarity to the discussion and the documentation.

  1. Move on once you agree, move on when you can’t agree, move on if something unclear can’t be clarified at the moment

i.Healthy discussion leads to the final conclusion of successful implementation of the software.

ii.Once reached to final statement recorded should move to the next step.

iii.If no conclusion is reached than that point should be left and move ahead with new implementation which is cost effective.

  1. Negotiation is not a contest or game
  2. Negotiation should be mutual not to put someone down or make them feel to be the loser.

5) Enlist TEN principle of Planning ?

OR

5) List any eight Planning Principle of software engineering?

Ans:

  1. Understand the scope of the project
    Involve the customer in the planning activity
    3. Recognize that planning is iterative
    4. Estimate based on what you know.
    5. Consider risk as you define the plan
    6. Be realistic
    7. Adjust granularity as you define the plan
    8. Define how you intend to ensure quality.
    9. Describe how you intend to accommodate change
    10. Track the plan frequently and make adjustments as required.

6) Enlist Analysis Modeling Principle?

Ans:

  1. The information domain of a problem must be represented and understood.
    2. The functions that the software performs must be defined.
    3. The behavior of the software (as a consequence of external events) must be represented.
    4. the models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered(or hierarchical) fashion.
    5. The analysis task should move from essential information toward implementation detail.
  • Enlist Software Design Modeling Principles?

Ans:                         

1 Design should be traceable to the analysis model.
2. Always consider architecture of the system to be built.
3. Design of data is as important as design of processing function
4. Interfaces must be designed with care (both external and internal)
5. User interface design should be designed to the needs of the end user.
6. Component level design should be functionally independent.
7. Components should be loosely coupled to one another and to the external environment.
8. Design representations (models) should be easily understandable.
9. The design should be developed iteratively. With each iteration the designer should strive for greater simplicity.

  • Explain the various elements of analysis modeling in detail?

Ans:

1] Scenario- based elements                                      

  • Use-cases- text
  • Use-case diagrams
  • Activity diagrams
  • Swim lane diagrams

2] Flow-Oriented elements

  • Data Flow diagrams
  • Control-flow diagrams
  • Processing narratives

3] Class – based elements

  • CRC models
  • Collaboration diagrams
  • Analysis packages
  • Class diagrams

4] Behavioral Elements

  • State Diagrams
  • Sequence Diagrams

Scenario based Elements :The system is described from the user‘s point of view using this approach. This is often the first part of analysis model that is developed to serve as input for the creation of other modeling elements.

Class-based Elements: Each usage scenario implies a set of objects that are manipulated as an actor interacts with the system. These objects are categorized into classes – a collection of things that have similar attributes and common behaviors.

Behavioral Elements :The behavior of the system can have profound effect on the design that is chosen. The analysis model must provide modeling elements that depict the behavior. The state diagram is one of the methods for representing behavior of a system.

Flow-Oriented Elements :The information is transformed as it flows through the computer based system. The system accepts inputs in a variety of forms, applies functions to transform it; and produces output in different forms. The transforms may comprise a single logical comparison, a complex numerical algorithm or an expert system. The elements of the information flow are included here.

8) What is SRS? Explain importance of SRS.

Ans:A Software requirements specification (SRS), a requirements specification for a software system, is a description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).

Software requirements specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do. Software requirements specification permits a rigorous assessment of requirements before.

The design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules. The software requirements specification document enlists enough and necessary requirements that are required for the project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed or being developed. This is achieved and refined with detailed and continuous communications with the project team and customer till the completion of the software.

9)  What is domain analysis? Explain with suitable examples

Ans:1] Software domain analysis is the identification, analysis and specification of common requirements from a specific application domain, typically for reuse in multiple projects within that application domain.

2] Object-oriented domain analysis is the identification, analysis and specification of common, reusable capabilities within a specific application domain, in terms of common objects, classes, subassemblies, and frameworks.

Example:The specific application domain can range from avionics to banking, from multimedia video game to software embedded within medical devices. Goal To find or create analysis classes and/or common functions those are broadly applicable, so that they may be reused.

Untitled

Figure: Domain Analysis

The role of domain analyst is to discover and define reusable analysis patterns, analysis classes and related information that may be used by many people working on similar but not necessarily the same applications.

10) Define the terms: Software Reliability and Software Availability.

Ans:

Reliability: – Software Reliability is probability of failure free operation of a system. It is calculated as follows MTBF = MTTF + MTTR where The acronyms MTTF and MTTR are mean-time-to-failure and mean-time-to- repair MTBF=Mean Time Between Failure.

Availability:-Software availability is the probability that a program is operating according to requirements at a given point in time and is defined as Availability = [MTTF/(MTTF + MTTR)]X100% The MTBF reliability measure is equally sensitive to MTTF and MTTR. The availability measure is somewhat more sensitive to MTTR, an indirect measure of the maintainability of software.

11)What is software deployment? State the principles to be followed while preparing to deliver the software increment.

Ans:  Software Deployment:

  • Deployment occurs as each software increment is presented to the customer and encompasses delivery, support, and feedback.
  • As modern software process models are evolutionary or incremental in nature, deployment happens not once, but a number of times as software moves toward completion.

Each delivery cycle provides the customer and end users with an operational software increment that provides usable functions and features.

Each support cycle provides documentation and human assistance for all functions and features introduced during all deployment cycles to date.

Each feedback cycle provides the software team with important guidance that result in modifications to the functions, features, and approach taken for the next increment. The delivery of a software increment represents an important milestone for any software project.

Deployment Principles:

  1. Principle 1: Customer expectations for the software must be managed: It always happens that customer wants more than he has started earlier as his requirements. It may be the case that customer gets disappointed, even after getting all his requirements satisfied. Hence at time of delivery developer must have skills to manage customers expectations.
  1. Principle 2: A complete delivery package should be assembled and tested: A CD-ROM or other media containing all executable software, support data files, support documents, and other relevant information should be assembled and thoroughly beta-tested with actual users. All installation scripts and other operational features should be thoroughly exercised in as many different computing configurations (i.e., hardware, operating systems, peripheral devices, networking arrangements) as possible.

3.Principle 3: A support regime must be established before the software is delivered: An end user expects responsiveness and accurate information when a question or problem arises. If support is ad hoc, or worse, nonexistent, the customer will become dissatisfied immediately. Support should be planned, support materials should be prepared, and appropriate recordkeeping mechanisms should be established so that the software team can conduct a categorical assessment of the kinds of support requested.

  1. Principle 4: Appropriate instructional materials must be provided to end users: Appropriate training aids (if required) should be developed; troubleshooting guidelines should be provided, and when necessary, a ―what‘s different about this software increment‖ description should be published
  1. Principle 5: Buggy software should be fixed first, delivered later: In incremental type of software, software organizations may deliver some defective software to the customer by giving assurance that the defects will be removed in next increment. This is a mistake. Buggy software should not be delivered.

12) Briefly describe the principles of coding.

Ans:  The principles which guide the coding tasks are programming languages, programming styles and programming methods

  1. Preparation principles: Before you write one line of code, be sure you
  • Understand of the problem you are trying to solve
  • Understand basic design, principles & concepts.
  • Pick a programming language that meets the needs of the software to be build and the environment in which the software will operate.
  • Select a programming environment that provides tools that will make you work simpler and easier.
  • Create a set of units that will be applied once the component you code is completed.
  1. Coding principles: As you begin writing code, be sure you:
  • Constrain your algorithms by following structured programming practice.
  • Consider the use of pair programming.
  • Select data structures that will meet the needs of the design.
  • Understand the software architecture and create interfaces that are consistent with it.
  • Keep conditional logic as simple as possible.
  • Create nested loops in a way that makes them easily testable.
  • Select meaningful variable names and follow other local coding standards.
  • Write code that is self-documenting.
  • Create a visual layout that aids understanding.

iii. Validation Principles: After you have completed your first coding pass, be sure you:

  • Conduct a code walkthrough when appropriate.
  • Perform unit tests and correct errors when you have uncovered.
  • Refactor the code.

13) With neat diagram explain analysis model.

Ans:(a) The model should focus on requirements that are visible within the problem or business domain and be written as a relatively high level of abstraction.

(b) Each element of the analysis model should add to the understanding of the requirements and provide insight into the information domain, function, and behaviour of the system.

(c) Delay consideration of infrastructure and other non-functional models until design.

(d) Minimize coupling throughout the system.

(e) Be certain the analysis model provides value to all stakeholders.

(f) Keep the model as simple as possible.

(g) The Figure  shows the structure of analysis modeling.

 Untitled

 

14)  Explain domain analysis with a neat diagram

Ans:

(a) Domain Analysis is the process that identifies the relevant objects of an application domain.

(b) The goal of Domain Analysis is Software Reuse.

The higher is the level of the life-cycle object to reuse, the larger are the benefits coming from its reuse, and the harder is the definition of a workable process.

  1. Concept and technical application domain of the software

(a) Frameworks are excellent candidates for Domain Analysis: they are at a higher level than code but average programmers can understand them.

(b) Umbrella activity involving the Identification, analysis, and specification of common requirements from a specific application domain, typically for reuse in multiple projects

(c) Object-oriented domain analysis involves the identification, analysis, and specification of reusable capabilities within a specific application domain in terms of common objects, classes, subassemblies, and frameworks

  1. Input and Output Structure of domain analysis

(a) Figure 5 shows the flow of the input and the output data in the domain analysis module.

(b) The main goal is to create the analysis classes and common functions.

(c) The input consists of the knowledge domain.

(d) The input is based on the technical survey, customer survey and expert advice.

(e) The output domain consists of using the input as the reference and developing the functional models

Untitled

Figure: Domain Analysis

15) What is Requirements Elicitation? What are the problems faced in eliciting requirements?

Ans:Elicitation

Elicitation means to draw out the truth or reply from anybody. In relation with requirement engineering, elicitation is a task that helps the customer to define what is required. To know the objectives of the system to be developed is a critical job. The problems faced in eliciting requirement are:

  1. Problem of Scope:

The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.

  1. Problem of understanding:

The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don‗t have full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be ―obvious, specify requirements that conflict with the needs of other customer/users or specify requirements that ambiguous or un-testable.

  1. Problems of volatility:

Volatility means change from one state to another. The customers requirement may change time to time.

16) With reference to requirement engineering, explain

(i) Inception and

(ii) Elicitation

Ans:

(i) Inception

Inception means beginning. It is always problematic to the developer that from where to start. The customer and developer meet and they decide overall scope and nature of the problem. The aim is

  1. To have the basic understanding of problem
  2. To know the people who will use the software
  3. To know exact nature of problem.

(ii) Elicitation :Elicitation means to draw out the truth or reply from anybody. In relation with requirement engineering, elicitation is a task that helps the customer to define what is required. To know the objectives of the system to be developed is a critical job.

  1. Problem of Scope:

The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.

  1. Problem of understanding:The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don‘t have full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be ―obvious‖, specify requirements that conflict with the needs of other customer/users or specify requirements that ambiguous or untestable.
  1. Problems of volatility :Volatility means change from one state to another. The customer‘s requirement may change time to time.

17) Enlist subtask included in Requirement Engineering(RE)?Explain any Three?

Ans:

  • Inception (software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers)
  • Elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis)
  • Elaboration (focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation)
  • Negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs)
  • Specification (written work products produced describing the function, performance, and development constraints for a computer-based system)
  • Requirements validation (formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products)
  • Requirements ManagementSet of activities that help project team to identify, control, and track requirementsand changes as project proceedsMany of these activities are identical to those that make up the software configuration management (SCM) processRequirements are first identified, tagged with a unique identifier and classified bytype (functional, data, behavioral, interface, or output)

18) What is software Testing?State the testing principle?

Ans:

Spiral Model

 Untitled

Agile Development Model

 Untitled

OR

 Untitled

Review Question  on Chapter-2

Q1)Describe any two core principle of software engineering?

Q2)Describe following requirement of engineering task

  1. Negotiation
  2. Validation
  3. Inception
  4. Elicitation

Q3)Explain Analysis Modeling Principle?

Q4)What are the major task of requirement engineering?

Q5)Explain Deployment principle?

Q6)What are modeling practices in software engineering? Explain their principle?

Q7)List software engineering core principle? Explain any two in detail?

Q8)State& describe six principle of communication practices?

Q9)Explain six design modeling principle?

Q10)State& Explain four principle of analysis modeling?

Q11)Describe in detail eight principle of good planning ?

Q12)What are RE?What is its need? Whatare subtask included in it?

Q13)Explain analysis modeling& Design modeling?

Q 14)Describe seven distinct function of requirement engineer

Leave a Reply

Your email address will not be published. Required fields are marked *