6 Change Authorization Software defects have to be analyzed once reported. The a

Question

6 Change Authorization

Software defects have to be analyzed once reported. The analysis is essential for both functional and economic reasons. Obviously, it is hard to make a decision about an identified defect until it is understood. At the same time, defects are not of equal magnitude, and it would be extremely resource-inefficient to simply fix problems as they crop up; problems need to be formally prioritized. That decision should be made by knowledgeable personnel within the organization. Otherwise, organizational time and resources could be wasted by individuals addressing problems that only affect them, or that are less critical when compared to other problems. Therefore, the decision to fix a problem should be authorized by a person with sufficient knowledge of the overall process.

Your CISO and the management team all want to have more of a say about changes to the applications that make up AAG's product line (model case is located in the Unit 6 Discussion item). Moreover, they want to be able to ensure that the organization's entire application portfolio is evolved based on the company's business strategy, rather than the whims of its programming staff. This level of control can be achieved if the owners of applications are responsible for authorizing changes to the application.

Therefore, the CISO wants you to define a management approach that allows the appropriate organizational role to authorize changes to applications. Organizationally, the process you develop should be hierarchical since all changes are not at the same level of importance. For example, programming managers should be allowed to make decisions about minor technical changes, while just upper level managers should be responsible for making decisions about major strategic changes to the product, such as new versions. That is because the latter type of change might require a change to the entire product line and perhaps even to the way the organization does business.

To begin this Discussion, go to Bugzilla and search for the term "security." Choose one item from the results list.

In your post, identify the item you chose and answer the following questions:

Explanation / Answer

Software engineering is about teams. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication. Teams do not consist only of developers, but also of testers, architects, system engineers, customer, project managers, etc. Software projects can be so large that we have to do careful planning. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics. They tell us if our code follows certain standards. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, we also need to learn a little about project management and its pitfalls, but especially what makes projects successful. And last but not least, a good software engineer, like any engineer, needs tools, and you need to know about them.

Developers Work in Teams

In your beginning semesters you were coding as individuals. The problems you were solving were small enough so one person could master them. In the real world this is different:- the problem sizes and time constraints are such that only teams can solve those problems.

For teams to work effectively they need a language to communicate (UML). Also teams do not consist only of developers, but also of testers, architects, system engineers and most importantly the customer. So we need to learn about what makes good teams, how to communicate with the customer, and how to document not only the source code, but everything related to the software project.

New Language

In previous courses we learned languages, such as Java or C++, and how to turn ideas into code. But these ideas are independent of the language. With UML we will see a way to describe code independently of language, and more importantly, we learn to think in one higher level of abstraction. UML can be an invaluable communication and documentation tool.

We will learn to see the big picture: patterns. This gives us yet one higher level of abstraction. Again this increases our vocabulary to communicate more effectively with our peers. Also, it is a fantastic way to learn from our seniors. This is essential for designing large software systems.

Measurement

Also just being able to write software, doesn

Related Questions

Navigate

• Browse (All)
• Browse 6
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.