Software Engineering

Published on December 2016 | Categories: Documents | Downloads: 41 | Comments: 0 | Views: 328
of 13
Download PDF   Embed   Report

Comments

Content

LPU
ASSIGNMENT NO3 OF PRINCIPLES OF SOFTWARE ENGINEERING
SUBMITTED TOSUBMITTED BYMR.AMANDEEP KATOCH VARUN

E3801B53 PART A Q1. As a project manager you have got the new project from the client, the client has provided you all the requirements he had, The project is basically of Marking Employee Attendance Online which is currently going Offline, now explain the approach you will use to develop this project with suitable reasons. Ans: Planning The important task in creating a software product is extracting the requirements or requirements analysis.Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gathered from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

Implementation, testing and documenting Implementation is the part of the process where software engineers actually program the code for the project.

Software testing is an integral and important part of the software development process. This part of the process ensures that defects are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal. Deployment and maintenance Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important and a lot of developers fail to realize that. It would not matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality of at least one prior phase is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and

commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.

Q2. Identify all the components of data flow diagrams first and then implement few of those in developing DFD for your software project.

Ans: EXTERNAL ENTITIES ON A DFD External entities are also known as terminators, sources/sinks, and actors. External entities define the sources and destinations of information entering and leaving the system. An external entity can be a person, system, or organization that has pre-defined behaviour.

External entities are mandatory on context diagrams but optional on data flow diagrams. Description of External Entities External entities are components that interact with a business process on the DFD but fall outside of the boundaries of the DFD. External entities can be: • initiators of data (i.e., spontaneous generators) flowing into the business process, end recipients of data (i.e., data sinks) flowing from the business process.



Examples Examples of external entities include: • • End User, Purchasing Department, • Inventory System.

Drawing External Entities on a DFD Place external entities on the diagram with all data flows. To reduce the visual complexity of the drawing, an external entity can be used more than once on the same DFD. Draw a diagonal line across the lowerleft corner of the external entity square to indicate another occurrence of the external entity elsewhere on the same DFD.

Document External Entities

Provide a description of external entities to support the DFD. FLOWS Definition Flows define the interfaces between the components within the system, and the system and its external components.

Types of Flows

Flows that transport data around the data flow diagram are called data flows. Description of Data Flows Data flows are the pipelines through which data are transmitted between any two components on a DFD. The composition of data is known and defined in a data dictionary. A data flow is also called a data flow vector. Examples of data flows are: • • • purchase order, customer profile, account number, • product.

Naming Data Flows Data flows must be given a name that describes the content of the data being transmitted and a

description of the data flow listing the data elements. For example:

Data Flow Name: Employee Info, Description: Information stored about an employee, Data elements: Employee Name, Employee Date of Birth, Employee ID.

Q3. Design the structure chart for the program which performs all the arithmetic operations on two integer numbers entered by the user with the help of the functions.

PART B Q1. As a debugger how will you identify different errors in software project? Suggest some techniques to avoid errors during coding.

1: Learn from other’s mistakes Find experienced peers who are willing to share their mistakes and then learn from them. I am somewhat biased, but the editors, writers, and members of TechRepublic seem willing to honestly share their mistakes — even if somewhat embarrassing at times. 2: Do your research first No matter how much you know, you’ll encounter new challenges on an almost daily basis. Each challenge usually requires you to learn something new. Before you tackle a problem or task, do your homework. The trial-and-error method of learning may have been necessary and acceptable years ago. But with the resources available on the Internet today, there is little excuse for mistakes made because you didn’t do the proper research in advance. 3: Have a plan You can’t know how to get to your destination without a roadmap. In project development, that roadmap is known as a project plan. Whether done formally or informally, you need to know how to get where you are going. Days or even weeks of programming time can be lost if the wrong path is taken. When done the right way, a project plan will help keep you from straying off course. 4: Follow standards and use templates There are good reasons why experienced professionals took the time to create and publish industry and company standards. Standards detail best practices and procedures learned over years of trial and error. Templates such as predefined forms can be useful since most of the work is already done in a standard format. A standard EULA approved by your legal counsel is another good example of a template that can come in handy if you are developing application software. A mistake in a legal document can be an expensive exercise — one best avoided.

5: Communicate and coordinate with others If you are part of a team, it’s essential to communicate with other team members to avoid redundancies and to coordinate your work with theirs. Emails, instant messages, project status reports, and teleconferences are all ways to communicate and coordinate with others on the team. Unfortunately, each of these is far from perfect. You can spend the better part of a day reading and writing emails, participating in conference calls, and instant messaging with your peers. But it is a necessary part of the development process. The perfect tool for communicating and coordinating with others in a team environment has yet to be developed. One of the better tools developed to share code is revision control software. Your project may also benefit from the use of a communication plan that ensures everyone involved — including customers and stakeholders — is kept apprised of key developments. (The TechRepublic downloads library has a free communication plan template to get you started.) 6: Allow enough time It was at Hughes Aircraft Company that I first heard the phrase “You want it bad – you got it bad.” It didn’t happen very often, but when it did it was almost always made in reference to a part from a vendor that was badly needed, rushed through production, and upon arrival, failed testing. Failure to allow enough time for each phase of the project can lead to missed requirements, inadequate analysis, poor design, rushed programming, insufficient testing, and incomplete documentation. The result can be a system that doesn’t meet expectations and fails in one or more key areas. Estimating the time needed to accomplish each phase of a project is difficult. I achieved the best results when I sat down with my supervisor and determined the time allotted for each major task in the project plan. I was overly optimistic in my estimates. He was much more realistic in his estimates, and he turned out to be right. As a rule of thumb, doubling my initial estimates came close

to the actual time required. That information was useful for developing project plan timelines. You may need to develop a similar rule of thumb until you can more accurately estimate completion dates. Ideally, you want to complete each phase of the project on time, and the best way to do that is estimate them correctly up front. Here are a few tips on creating realistic schedules. 7: Reuse proven code If you’re an experienced developer, you should have built up a large code base over the years. Go blue and recycle this code whenever possible. You will likely have to modify the code to fit the new requirements, but proven core code is a good foundation to build on. Not only will you reduce the risk of introducing new bugs, but you will eliminate the time wasted creating similar code and the subsequent testing required. Share your code with others so they can reuse parts of it. Proven code can be shared via plug-ins or libraries. Good external sources of code are available on the Internet that can be legally used for free or for a small fee. 8: Use checklists Before a commercial plane trip, the pilot and co-pilot are busy walking through a long, detailed checklist. Checklists can be used during various phases of the project development process. They are particularly useful when working with large systems and when a single person is responsible for multiple tasks. For example, a list detailing the steps required for system turn-on will help avoid accomplishing tasks out of order and prevent errors of omission. It is all too easy for developers to overlook important items like system access when they are busy doing final testing and documentation. For more on the virtues of using checklists, see Leverage checklists to improve efficiency and client satisfaction.

9: Test, test, test… and carefully review your work There is a healthy level of paranoia about delivering error-free work. Test as much as possible as early as possible. Errors in the code are typically more expensive to correct when found near the end of the development process. The last thing you need when facing a critical release date is to find a bug that should have been found months ago. Careful and thorough testing will allow you to find those mistakes before your users can. Double- and triple-check your work. Develop test data and a plan to test common calendar-based events like EOM processing and annual reporting. All functionality and every single possible scenario should be thoroughly tested. And, yes, this is also a good place to use a checklist. 10: Test again with a third party Find at least one experienced person who can be dedicated to the beta testing. They will undoubtedly use the system in ways you never dreamed of and find bugs you missed. Don’t overlook or rush this final quality assurance task. It’s typically your last chance to get it right. Once a bad piece of software is released or a system with a critical bug is turned on, a company’s image can be tarnished for years to come.

Q2. Create algorithm design document for any software project. In mathematics, computer science, and related subjects, an algorithm is an effective method for solving a problem using a finite sequence of instructions. Algorithms are used for calculation, data processing, and many other fields. Each algorithm is a list of well-defined instructions for completing a task. Starting from an initial state, the instructions describe a computation that proceeds through a well-defined series of successive states, eventually terminating in a final ending state.

The transition from one state to the next is not necessarily deterministic; some algorithms, known as randomized algorithms, incorporate randomness.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close