Question

The stages of the classical waterfall model for software development consist of requirements, design, implementation, testing, deployment, and maintenance. Why does picturing the development of software to run on mobile applications, business-based systems, or Internet environments help to ensure the success of the development effort? What might happen otherwise? What is the professionalism with respect to software engineering? What do you do, as a software engineer involved in a software systems development project, to ensure that the product is better because of your participation in the development effort?

Answer any 3 questions

Answer 1

1. What do you do, as a software engineer involved in a software systems development project, to ensure that the product is better because of your participation in the development efforts

Answer:- The fundamental rules of software Engineering:-

1)      If you dont do a system architectural design with well-defined interfaces, integration will be a big mess.

2)      Design before coding.

3)      If a project is late and you add more people, the project will be even later [3].

4)      Team members that are new to a project are less productive (1/3 to 2/3 less) than the adequately trained people.

5)      The average newly hired employee is about as productive as an experienced employee

6)      Two factors that affect productivity are work force experience level and level of project familiarity due to learning-curve effects

7)      Developers  productivity varies greatly depending on their individual skills (experience concerning a development activity, knowledge of the tools, methods, and notations used, etc.)

8)      Using better and fewer people is more productive than using more less qualified people

9)      The greater the number of developers working on a task simultaneously, the faster that task is finished, but more overall effort is required due to the growing need for communication among developers. Thus, the productivity of the individual developer decreases [2].

10)  The earlier problems are discovered, the less the overall cost will be [7].

11)  The error detection effectiveness of reviews depends greatly on the qualifications and preparations of the reviewers and the completeness and correctness of the documents used as a reference [14].

12)  Reviews of non-technical documents (e.g., requirements specification, user manual) are more effective if the customer is involved [10].

13)  Develop tests before doing the coding.

14)  Extreme time pressure leads to decreased productivity [7].

15)  Extreme time pressure leads to a faster rate at which errors are made, which leads to a further delay in the completion date [9].

16)  Error correction is most efficiently done by the documents author(s) [7].

17)  The more errors a document from a previous phase contains, the more errors will be passed on to the next document [7].

18)  Always test everything.

19)  Talk to users, not to customers to verify the prototype.

20)  Inspection is the most cost-effective measure of finding problems in software.

21)  Software inspections find a high percentage of errors early in the development life cycle [13].

22)  The use of inspections can lead to defect prevention, because developers get early feedback with respect to the types of mistakes they are making [13].

23)  Every group has one programmer that is 10 times more productive than everyone else.

24)  If you disable Internet surfing, productivity will go down.

25)  The number of meetings is determined by the kinds of processes used.

2.What is the professionalism with respect to software engineering?

Answer:-  Software professionalism is arguably one of the most important aspects of software engineering yet it is rarely discussed. Software touches every aspect of our lives on a daily basis, from personal interactions all the way up through enterprise transactions. Our data is stored in these systems and most of us put our livelihood in their hands. The truth is, our end users trust the software engineers to protect them and protect their information. It is our responsibility to do everything in our power to ensure the software we write exemplifies who we are as professionals. A professional is typically: an expert in their field, extremely hard working, motivated and dedicated to producing quality results with no mistakes. Doctors are a great example of a profession that I associate with true professionalism. They work very hard, require a high level of training and skill, and they do everything in their power to make sure they make no mistakes. Doctors work in a very high stakes environment where the health of another person is in their hands. I would argue that the same could be said about developers. While not every application we build is going to be critical to the health of another person, the enterprise applications we build as Force.com developers are critical to the business. These businesses depend on our applications to support their everyday work functions. At the heart of it, the employees and shareholders of these businesses trust us to run their business on our software. That is a huge responsibility and one we absolutely cannot take lightly. If we make a mistake, we could lose major revenue for one of our customers. All of a sudden, that company could suffer and other people’s jobs could be at risk. That is why it is so crucial. This is why we must be professional.

3.The stages of the classical waterfall model for software development consist of requirements, design, implementation, testing, deployment, and maintenance

Answer:- Classical waterfall model is the basic software development life cycle model. It is very simple but idealistic. Earlier this model was very popular but nowadays it is not used. But it is very important because all the other software development life cycle models are based on the classical waterfall model.
Classical waterfall model divides the life cycle into a set of phases. This model considers that one phase can be started after completion of the previous phase. That is the output of one phase will be the input to the next phase. Thus the development process can be considered as a sequential flow in the waterfall. Here the phases do not overlap with each other. The different sequential phases of the classical waterfall model

1. Feasibility Study: The main goal of this phase is to determine whether it would be financially and technically feasible to develop the software.
   The feasibility study involves understanding the problem and then determine the various possible strategies to solve the problem. These different identified solutions are analyzed based on their benefits and drawbacks, The best solution is chosen and all the other phases are carried out as per this solution strategy.
2. Requirements analysis and specification: The aim of the requirement analysis and specification phase is to understand the exact requirements of the customer and document them properly. This phase consists of two different activities.
   • Requirement gathering and analysis: Firstly all the requirements regarding the software are gathered from the customer and then the gathered requirements are analyzed. The goal of the analysis part is to remove incompleteness (an incomplete requirement is one in which some parts of the actual requirements have been omitted) and inconsistencies (inconsistent requirement is one in which some part of the requirement contradicts with some other part).
   • Requirement specification: These analyzed requirements are documented in a software requirement specification (SRS) document. SRS document serves as a contract between development team and customers. Any future dispute between the customers and the developers can be settled by examining the SRS document.
3. Design: The aim of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language.
4. Coding and Unit testing: In coding phase software design is translated into source code using any suitable programming language. Thus each designed module is coded. The aim of the unit testing phase is to check whether each module is working properly or not.
5. Integration and System testing: Integration of different modules are undertaken soon after they have been coded and unit tested. Integration of various modules is carried out incrementally over a number of steps. During each integration step, previously planned modules are added to the partially integrated system and the resultant system is tested. Finally, after all the modules have been successfully integrated and tested, the full working system is obtained and system testing is carried out on this.