te/insem-643 te (information technology) software … · 2018. 8. 23. · prepared by: prof v. k....

Prepared By: Prof V. K. Wani SNJB’s KBJ CoE Chandwad

TE/INSEM-643 TE (Information Technology)

SOFTWARE ENGINEERING & PROJECT MANAGEMENT (2015 Pattern) (Semester I)

Solution Set Paper Code: P5094 Q1. A Software Myths:

The development of software requires dedication and understanding on the developers' part. Many software problems arise due to myths that are formed during the initial stages of software development. Unlike ancient folklore that often provides valuable lessons, software myths propagate false beliefs and confusion in the minds of management, users and developers. Table Management Myths

The members of an organization can acquire all-the information, they require from a manual, which contains standards, procedures, and principles;

Standards are often incomplete, inadaptable, and outdated. Developers are often unaware of all the established

standards. Developers rarely follow all the known standards because

not all the standards tend to decrease the delivery time of software while maintaining its quality.

If the project is behind schedule, increasing the number of programmers can reduce the time gap.

Adding more manpower to the project, which is already behind schedule, further delays the project.

New workers take longer to learn about the project as compared to those already working on the project.

If the project is outsourced to a third party, the management can relax and let the other firm develop software for them.

Outsourcing software to a third party does not help the organization, which is incompetent in managing and controlling the software project internally. The organization invariably suffers when it out sources the software project.

In most cases, users tend to believe myths about the software because software managers and developers do not try to correct the false beliefs. These myths lead to false expectations and ultimately develop dissatisfaction among the users. Common user myths are listed in Table.

Table User Myths

Brief requirement stated in the initial process is enough to start development; detailed requirements can be added at the later stages.

Starting development with incomplete and ambiguous requirements often lead to software failure. Instead, a complete and formal description of requirements is essential before starting development.

Adding requirements at a later stage often requires repeating the entire development process.

Software is flexible; hence software requirement changes can be added during any phase of the development process.

Incorporating change requests earlier in the development process costs lesser than those that occurs at later stages. This is because incorporating changes later may require redesigning and extra resources.


In the early days of software development, programming was viewed as an art, but now software development has gradually become an engineering discipline. However, developers still believe in some myths-. Some of the common developer myths are listed in Table.

Table Developer Myths

Software development is considered complete when the code is delivered.

50% to 70% of all the efforts are expended after the software is delivered to the user.

The success of a software project depends on the quality of the product produced.

The quality of programs is not the only factor that makes the project successful instead the documentation and software configuration also playa crucial role.

Software engineering requires unnecessary documentation, which slows down the project.

Software engineering is about creating quality at every level of the software project. Proper documentation enhances quality which results in reducing the amount of rework.

The only product that is delivered after the completion of a project is the working program(s).

The deliverables of a successful project includes not only the working program but also the documentation to guide the users for using the software.

Software quality can be assessed only after the program is executed.

The quality of software can be measured during any phase of development process by applying some quality assurance mechanism. One such mechanism is formal technical review that can be effectively used during each phase of development to uncover certain errors.

Q1. B. What is Capability Maturity Model? The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an increasing series of levels of a software development organization. The higher the level, the better the software development process, hence reaching each level is an expensive and time-consuming process.


Level One :Initial - The software process is characterized as inconsistent, and occasionally even chaotic. Defined processes and standard practices that exist are abandoned during a crisis. Success of the organization majorly depends on an individual effort, talent, and heroics. The heroes eventually move on to other organizations taking their wealth of knowledge or lessons learnt with them.

Level Two: Repeatable - This level of Software Development Organization has a basic and consistent project management processes to track cost, schedule, and functionality. The process is in place to repeat the earlier successes on projects with similar applications. Program management is a key characteristic of a level two organization.

Level Three: Defined - The software process for both management and engineering activities are documented, standardized, and integrated into a standard software process for the entire organization and all projects across the organization use an approved, tailored version of the organization's standard software process for developing,testing and maintaining the application.

Level Four: Managed - Management can effectively control the software development effort using precise measurements. At this level, organization set a quantitative quality goal for both software process and software maintenance. At this maturity level, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable.

Level Five: Optimizing - The Key characteristic of this level is focusing on continually improving process performance through both incremental and innovative technological improvements. At this level, changes to the process are to improve the process performance and at the same time maintaining statistical probability to achieve the established quantitative process-improvement objectives.

Q 2. A Validation & Verification V & V are the Part of Requirements engineering which helps software engineers better understand the problems they are trying to solve. The requirements engineering process begins with inception, moves on to elicitation, negotiation, problem specification, and ends with review or validation of the specification

There seems to be much confusion over the terms verification and validation. Many people and even QA analysts talk about and even perform V&V as though they are one and the same. However, these activities are not the same.

Validation is the process of confirming the completeness and correctness of requirements. Validation also ensures that the requirements: 1) achieve stated business objectives, 2) meet the needs of


stakeholders, and 3) are clear and understood by the developers. Validation is essential to identification of missing requirements and to ensure that the requirements meet certain quality characteristics. Validation addresses each individual requirement to ensure that it is:

Correct – accurately states a customer or external need Clear – has only one possible meaning Feasible – can be implemented within known constraints Modifiable – can be easily changed, with history, when necessary Necessary – documents something customers really need Prioritized – ranked as to importance of inclusion in product Traceable – can be linked to system requirements, and to designs, code, and tests Verifiable – correct implementation can be determined by testing, inspection, analysis, or

demonstration

Verification is the process of confirming that the designed and built product fully addresses documented requirements. Verification consists of performing various inspections, tests, and analyses throughout the product lifecycle to ensure that the design, iterations, and the finished product fully addresses the requirements. To prevent rework, requirements should be validated and approved before design. If the requirements are not validated, then requirement validation and product verification will inevitably be done together during product design and development activities. Because verification is guided by requirements, there is high likelihood that missing or invalid requirements will not be discovered. Missing and invalid requirements causes rework and significant cost overruns.Note that the last quality characteristic listed above is “Verifiable.” Assessing verification as you develop your requirements and validating that the requirements are verifiable significantly improves requirement quality.

Validating that your requirements support verification provides a basis for estimating verification costs and schedule and reduces verification costs. An unverifiable requirement is a bad or unnecessary requirement; if you can not verify it, then you can not design it or build it. For example, take the requirement “The product must be reliable.” What is reliable? If you can’t define what reliable is, how will designers know what reliable is? If you can’t verify a requirement you may not be able to convince your customer that your product is reliable.Risk management is one of the key responsibilities of the project manager. Ensuring that development begins with verifiable requirements is key to reducing risk. Carefully reviewing each requirement to ensure that it is verifiable and either eliminating or requesting rewrites of requirements that are not verifiable is an important activity in the requirements development process. The Enfocus Solutions Requirement Suite™ provides tools and underlying support to ensure effective documentation, verification and validation of requirements.

3. Q2. B. Incremental Model

The incremental model applies the waterfall model incrementally. The series of releases is referred to as “increments”, with each increment providing more functionality to the customers. After the first increment, a core product is delivered, which can already be used by the customer. Based on customer feedback, a plan is developed for the next increments, and modifications are made accordingly. This process continues, with increments being delivered until the complete product is delivered. The incremental philosophy is also used in the agile process model (see agile modeling).


Characteristics of Incremental Model

1. System is broken down into many mini development projects. 2. Partial systems are built to produce the final system. 3. First tackled highest priority requirements. 4. The requirement of a portion is frozen once the incremented portion is developed.

Q 3. A Data Flow Diagram Level 0 & Level 1 Diagram Data Flow Diagram: 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. Data flowcharts can range from simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively deeper into how the data is handled. A level 0 data flow diagram (DFD), also known as a context diagram, shows a data system as a whole and emphasizes the way it interacts with external entities. This DFD level 0 example shows how such a system might function within a typical retail business. The Level 1 DFD shows how the system is divided into sub-systems (processes), each of which deals with one or more of the data flows to or from an external agent, and which together provide all of the functionality of the system as a whole. The DFD Can be extended up to level 7. DFD Level 0: A context diagram is a top level (also known as "Level 0") data flow diagram. It only contains one process node ("Process 0") that generalizes the function of the entire system in relationship to external entities. DFD Layers. Draw data flow diagrams can be made in several nested layers. DFD Level 1 :A level 1 data flow diagram (DFD) is more detailed than a level 0 DFD but not as detailed as a level 2 DFD. It breaks down the main processes into subprocesses that can then be analyzed and improved on a more intimate level.


DFD Level 0 DFD Level 1

Q 3. B Requirements Negotiation It includes Discussion for to rank the requirements, to Decide Priority , Decide risk, to decide Project cost and etc. The requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs) To negotiate the requirements of a system to be developed, it is necessary to identify conflicts and to resolve those conflicts. This is done by means of systematic conflict management. The conflict management in requirements engineering comprises the following four tasks:

Conflict identification Conflict analysis Conflict resolution Documentation of the conflict resolution

These four tasks are explained in the following sections.

Conflict Identification: Conflicts can arise during all requirements engineering activities. For example, different stakeholders can utter contradicting requirements during elicitation. Conflicts between requirements and conflicts between stakeholders are often not obvious due to different reasons. During the entire requirements engineering process, the requirements engineer should pay attention to potential conflicts so that they can be identified, analyzed, and resolved early on.

Conflict Analysis: During conflict analysis, the reason for an identified conflict must be determined. According to different types of conflicts exist.


Conflict Resolution: Conflict resolution is very important for requirements negotiation because the strategy of conflict resolution has a big influence on the willingness of the people involved (e.g., customers, consultants, or developers) to continue working together. For example, a conflict resolution considered unfair by at least one party of the conflict can lead to a decreased engagement and willingness to collaborate in the project. On the other hand, a resolution that is considered fair by all parties can increase the willingness to cooperate because this signals that everyone’s ideas about the planned system are being considered.

Documentation of the Conflict Resolution: Conflicts cannot be avoided during requirements engineering. A resolution to a conflict must always be traceably documented. If a conflict resolution is not properly documented, the following threats (among others) to the project may arise. Q4. A Software Requirements Specification (SRS)

A software requirements specification (SRS) is a description of a software system to be developed. The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide. In short, the purpose of this SRS document is to provide a detailed overview of our software product, its parameters and goals. This document describes the project's target audience and its user interface, hardware and software requirements.

Characteristics of requirements and SRS

1. Complete: The requirements must be complete, what is the meaning of completeness? It means that all the required information to implement (read Code) the requirement. There is no need to assume anything in order to implement the same. One of the important aspects of completeness is to also have measuring units, if applicable.

2. Consistent: Consistency is an important aspect of requirements. It means that all inputs to any process, must be processed similarly. It should not happen that processes produce different outputs for inputs coming from different sources. Consistent requirements also mean that you will not find a contradicting information in the SRS document.

3. Feasible: This is one of the crucial part of requirements capturing. All the requirements included in the SRS must be feasible to implement. A requirement to be feasible must be: Implementable within the given time frame and budget Implementable using the existing and chosen technology platform A feature, which will be used by the end users

4. Modifiable: Every SRS document must be modifiable. In the modern software projects, requirements are never static and don’t stop coming after the SRS document is signed off. We can’t expect the customers to stop altering the requirements or adding new requirements as we also need to look at business needs. So the best way to manage the requirements is to manage these changes. In order to do so, we must have an SRS, which clearly identifies each and every requirement in a systematic manner. In case of any changes, the specific requirements and the dependent ones can be modified accordingly without impact the others.

5. Unambiguous: Unambiguous means a single interpretation. If a requirement is defined in such a manner that it can only be interpreted in one way, it means that the requirement is unambiguous. All subjective words or statements must be eliminated from the requirements.


6. Testable: A testable requirement can be defined as a requirement, which can be tested and validated using any of the following methods are Inspection, Walkthrough, Demonstration, Testing.

SRS Template:

Q4. B Class Diagram for College Technical Event

Class Diagram: In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among objects. Class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modeling of object oriented systems because they are the only UML diagrams, which can be mapped directly with object-oriented languages. Class. A class represents a relevant concept from the domain, a set of persons, objects, or ideas that are depicted in the IT system.


Q 5. A software proposal and contract

Software Proposal is a professional proposal suite that has been designed to facilitate the bidding process of software engineers and software development companies, as well as to enhance the winning rates of new IT projects.

Steps for Writing software proposal

1. Start with a firm introduction. This should start out with a hook. 2. State the problem. After the introduction, you'll get into the body, the meat of your work. 3. Propose solutions. 4. Include a schedule and budget. 5. Wrap up with a conclusion. 6. Edit your work. 7. Proofread your work.

Software contracts. A software contract is a binding agreement between the owner of a software product and a buyer. The contract enables the buyer to use the software legally. In the base system, you can manage and track software contracts with the Contract Management application

Q 5 B Effort Estimation & Scheduling

For a project total cost and duration has to be committed in start Requires effort estimation, often in terms of person-months Effort estimate is key to planning - schedule, cost, resources depend on it Many problems in project execution stem from improper estimation No easy way, no silver bullet Estimation accuracy can improve with more information about the project Early estimates are more likely to be inaccurate than later


Effort Estimation Models

A model tries to determine the effort estimate from some parameter values A model also requires input about the project, and cannot work in vacuum So to apply a model, we should be able to extract properties about the system Two types of models

o top-down and o bottom-up

The project schedule is the tool that communicates what work needs to be performed, which resources of the organization will perform the work and the timeframes in which that work needs to be performed. The project schedule should reflect all of the work associated with delivering the project on time.

Project Scheduling Techniques: 1. CRM (Critical Path Method) : The critical path method (CPM), or critical path analysis (CPA), is an

algorithm for scheduling a set of project activities. It is commonly used in conjunction. 2. PERT( Program Evaluation and Review Technique): The program (or project) evaluation and

review technique, commonly abbreviated PERT, is a statistical tool, used in project management, which was designed to analyze and represent the tasks involved in completing a given project.

Extract Estimation Model

Values of somecharacteristics

Effort Estimate

Knowledge aboutSW project


Q6 A. Network Diagram:

A Network Diagram is a graphical way to view tasks, dependencies, and the critical path of your project. Boxes (or nodes) represent tasks, and dependencies show up as lines that connect those boxes.

Q 6 B. project scope management

Project scope is the part of project planning that involves determining and documenting a list of specific project goals, deliverables, features, functions, tasks, deadlines, and ultimately costs. In other words, it is what needs to be achieved and the work that must be done to deliver a project. Project scope management involves planning the project scope in a scope management plan, defining the project scope in a project scope statement, developing a work breakdown structure (WBS), decomposing and outlining the tasks involved in the project and their planned completion times, controlling changes to project

The purpose of Scope Management is to ensure the project includes all the work required, and only the work required, for completing the project successfully. In scope management the emphasis is on identifying and controlling what is or is not included in the project

te/insem-643 te (information technology) software … · 2018. 8. 23. · prepared by: prof v. k....

Documents