1. List two key reasons that have caused both software project successes and fai
ID: 2247025 • Letter: 1
Question
1. List two key reasons that have caused both software project successes and failures.
2. From the definition of software engineering, list three areas that software engineering must touch on.
3. List two of the three strategies cited by the 2004 U.S. General Accounting Office report as key to ensuring delivery of successful software.
4. When and where was the term software engineering first introduced.
5. What are the eight principles for software engineering code of ethics recommended by the IEEE-CS/ACM Version 5.2 join task force report?
6. What is meant by the term principles of software engineering?
7. Can a software engineer become a certified Professional Engineer (PE)? Explain.
Explanation / Answer
Ques. Key reasons for a software project success and failure?
Answer. Before we go on to discuss why projects fail, let’s take a look at how different companies define successful projects:
We believe that project success is not black-and-white. According to “Measurement of Project Success,” an article published in the International Journal of Project Management, there is a distinction between project success and project management success. While product/project success is largely determined by meeting its objectives, project management success is based on time, cost, and scope of criteria.
Therefore, a project that is not on-time, on-budget, and on-value may not be a “failed product/project.” Success should take both product/project success and project management success into consideration.
Instead of categorizing projects as either “successful” or “unsuccessful”, they can be categorized like so:
Now, Project Failure will/can depend on these factors :-
Poor Preparation
You need to have a clear picture of what you’re going to do, in advance – as much as possible. Otherwise, you may find yourself up stream without a paddle. You need to know what project success looks like at the beginning and don’t loose focus of it. Hence, if you don’t have a clear focus at the at the earliest stage of the process, you are making things harder on yourself. Have a meeting, even if it is lengthy, with stakeholders to discuss their expectations on cost, time and product quality. Know how you will execute your tasks in order to meet everyone’s expectations.
Inadequate Documentation and Tracking
This is the responsibility of the project manager. Tracking milestones is how you are going to know whether you are meeting expectations. Proper recording and monitoring lets the PM identify where more resources are needed to complete a project on time.
Bad Leadership
When we see this word, leader, we usually think, the project manager. However, the people at each management-level have a responsible to ensure that the project is successful. Management should not micromanage but provide support to ensure that the PM can follow through with the expectations placed upon them.
Failure to Define Parameters and Enforce Them
When you’re a leader, PM, it’s imperative that you’re able to work well with your team. If and when tasks or goals are not met to standard, there should be ramifications. Rank tasks by priority and assign them to the most proficient individual.
Ques. List three areas that software engineering must touch on?
Answer. Software engineering is the study and application of engineering to the design, development, and maintenance of software. Typical formal definitions of software engineering are: “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
Computer software engineers apply the principles and techniques of computer science, engineering, and mathematical analysis to the design, development, testing, and evaluation of the software and the systems that enable computers to perform their many applications.
Typically software engineers, working in applications or systems development, analyze first the needs of the user. They then design, construct, test, and maintain computer applications software or systems to meet these needs.
In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, and project management. It is also known as a software development life cycle.
A software development process comprises different phases. These phases follow a top-to-bottom approach, implying that the phases take inputs from the previous phases, add features, and then produce outputs. The outputs from different phases are referred to as intermediate product, work product, or derivable. Various phases involved in the systematic development of software.
Ques. When and where term software engineering first introduced?
Answer. The term 'software engineering' was suggested at conferences organized by NATO in 1968 and 1969 to discuss the 'software crisis'. The software crisis was the name given to the difficulties encountered in developing large, complex systems in the 1960s.
In August 1996 about a dozen historians met with about a dozen computer scientists to discuss the history of software engineering. The term software engineering has been deliberately chosen as being provocative at the 1968 NATO Conference on Software Engineering. This notion was meant to imply that software manufacture should be based on the types of theoretical founda- tions and practical disciplines that are established in the traditional branches of engineering. This need was motivated by the so-called software crisis. Ever since, the debate whether such a crisis exists has continued within the software engineering community. It is a crucial question, because if the answer is yes, software engineering may not be called an engineering discipline yet. If the answer were no, the question would be, what is it that constitutes this discipline
Ques. What is meant by the term principles of software engineering?
Answer. There are seven basic principles of software engineering
1. Separation of Concerns
When specifying the behavior of a data structure component, there are often two concerns that need to be dealt with: basic functionality and support for data integrity. A data structure component is often easier to use if these two concerns are divided as much as posible into separate sets of client functions. It is certainly helful to clients if the client documentation treats the two concerns separately. Further, implementation documentation and algorithm descriptions can profit from separate treatment of basic algorithms and modifications for data integrity and exception handling.
There is another reason for the importance of separation of concerns. Software engineers must deal with complex values in attempting to optimize the quality of a product.
In view of this, it makes sense to separate handling of different values. This can be done either by dealing with different values at different times in the software development process, or by structuring the design so that responsibility for achieving different values is assigned to different components.
As an example of this, run-time efficiency is one value that frequently conflicts with other software values. For this reason, most software engineers recommend dealing with efficiency as a separate concern. After the software is design to meet other criteria, it's run time can be checked and analysed to see where the time is being spent.
2. Modularity
The principle of modularity is a specialization of the principle of separation of concerns. Following the principle of modularity implies separating software into components according to functionality and responsibility.
3. Abstraction
The principle of abstraction is another specialization of the principle of separation of concerns. Following the principle of abstraction implies separating the behavior of software components from their implementation. It requires learning to look at software and software components from two points of view: what it does, and how it does it.
Failure to separate behavior from implementation is a common cause of unnecessary coupling. For example, it is common in recursive algorithms to introduce extra parameters to make the recursion work. When this is done, the recursion should be called through a non-recursive shell that provides the proper initial values for the extra parameters. Otherwise, the caller must deal with a more complex behavior that requires specifying the extra parameters. If the implementation is later converted to a non-recursive algorithm then the client code will also need to be changed.
4. Anticipation of Change
Computer software is an automated solution to a problem. The problem arises in some context, or domain that is familiar to the users of the software. The domain defines the types of data that the users need to work with and relationships between the types of data.
Software developers, on the other hand, are familiar with a technology that deals with data in an abstract way. They deal with structures and algorithms without regard for the meaning or importance of the data that is involved. A software developer can think in terms of graphs and graph algorithms without attaching concrete meaning to vertices and edges.
Working out an automated solution to a problem is thus a learning experience for both software developers and their clients. Software developers are learning the domain that the clients work in. They are also learning the values of the client: what form of data presentation is most useful to the client, what kinds of data are crucial and require special protective measures.
The clients are learning to see the range of possible solutions that software technology can provide. They are also learning to evaluate the possible solutions with regard to their effectiveness in meeting the clients needs.
5. Generality
The principle of generality is closely related to the principle of anticipation of change. It is important in designing software that is free from unnatural restrictions and limitations. One excellent example of an unnatural restriction or limitation is the use of two digit year numbers, which has led to the "year 2000" problem: software that will garble record keeping at the turn of the century. Although the two-digit limitation appeared reasonable at the time, good software frequently survives beyond its expected lifetime.
6. Incremental Development
Fowler and Scott [FS97] give a brief, but thoughtful, description of an incremental software development process. In this process, you build the software in small increments; for example, adding one use case at a time.
An incremental software development process simplifies verification. If you develop software by adding small increments of functionality then, for verification, you only need to deal with the added portion. If there are any errors detected then they are already partly isolated so they are much easier to correct.
A carefully planned incremental development process can also ease the handling of changes in requirements. To do this, the planning must identify use cases that are most likely to be changed and put them towards the end of the development process.
7. Consistency
The principle of consistency is a recognition of the fact that it is easier to do things in a familiar context. For example, coding style is a consistent manner of laying out code text. This serves two purposes. First, it makes reading the code easier. Second, it allows programmers to automate part of the skills required in code entry, freeing the programmer's mind to deal with more important issues.
Consistency serves two purposes in designing graphical user interfaces. First, a consistent look and feel makes it easier for users to learn to use software. Once the basic elements of dealing with an inteface are learned, they do not have to be relearned for a different software application. Second, a consistent user interface promotes reuse of the interace components. Graphical user interface systems have a collection of frames, panes, and other view components that support the common look. They also have a collection of controllers for responding to user input, supporting the common feel. Often, both look and feel are combined, as in pop-up menus and buttons. These components can be used by any program.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.