SOFTWARE ENGINEERING ETHICS IN A DIGITAL WORLD.

SOFTWARE ENGINEERING ETHICS IN A DIGITAL WORLD.

In this modern world almost everything that has to do with us is about internet. There’s a lot of activities that we can do with it, socialize, entertainment, finding information, looking for inspiration and many more. But there is a consequence to this; if the security of the system not secure enough, hackers may easily break to our personal information. This is what we called the dual-use dilemma. There is always pros and cons to it. We can take Google maps for example, it could be a lot of help for us to find a map for a place or destination that we are not familiar to, but the cons of the application is, it also looked as invasion of privacy, people can easily locate where our house is when they got the address. Software engineer faces three key challenges to designing system for the digital world, it’s called the three ethical challenges. The first challenge is right to privacy versus the need to protect vulnerable users. Freedom of choice versus protection from harm and context dependent. These challenges cannot be faced by software engineer alone, they need help from the law-makers, and social scientist. Not to be forgotten there is five key challenge that software engineers must face over the next 5 to 10 years, it is how to understand ethics requirement from the different stake holder, to conduct tradeoff analysis involving ethics considerations when making architectural and design choices, how to validate and test that the system whether it meets the ethical considerations and associated design tradeoff, to incorporate ethics awareness practice in existing software engineering methodologies and processes, and to train the software engineer in ethic software design.

Module 10: Advanced Topics in Software Engineering

What is SPI?

The term software process improvement (SPI) implies many things:

• elements of an effective software process can be defined in an effective manner.
• an existing organizational approach to software development can be assessed against those elements.
• a meaningful strategy for improvement can be defined.

Approaches to SPI

Maturity Model

A maturity model is applied within the context of an SPI framework. The intent of the maturity model is to provide an overall indication of the "process maturity" exhibited by a software organization. That is :

• an indication of the quality of the software process, the degree to which practitioner's understand and apply the process.
• the general state of software engineering practice.

The CMMI

The Capability Maturity Model Integration (CMMI) is a comprehensive process meta-model that is predicated on a set of system and software engineering capabilities that should be present as organizations reach different levels of process capability and maturity.

The CMMI represents a process meta-model in two different ways:

• "continuous" model
• "staged " model

Trends in SE



Software Engineering Ethics

1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Module 9 : Software Project Management

Software Project Management (SPM)

Importance of SPM

• Building computer software is complex, particularly if it involves many people working over a relatively long time.
• Software projects need to be managed!

The Management Spectrum

Effective software project management focuses on the four P's :

Click to enlarge the image

The W5HH Principle

A series of a question that lead to a definition of key project characteristic and the resultant project plan.

• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they organizationally located?
• How will the job be donetechnically and managerially?
• How much of each resources

Critical Practices

1. Defect tracking

• Requires that quality targets be set and that tracked defects be analyzed against those targets

2. Earned value tracking

• Quarantine technique for assessing progresses the software team progresses through the work tasks allocated to the project schedule.

3. People aware management

• Management of people that involve in project.

Module 8 : Software Evolution

Software Maintenance

Software maintenance is the process where after the software been released to end user, there will be:-

• Abug reports about the software
• Changes that need to be done to suit one class of user.
• A few adjustments on the software for another corporate company that have seen unexpected benefits on the software.

This is among of the work that can be called software maintenance.

Software maintenance and support.

• Ongoing activities to change and support the software after it is in operation.

-No degrade or require periodic maintenance.
-Software continually evolving.

• For example :-
- Correcting defects
- Adapting application according to the business environment.
- Implementing enhancement according to the request of the shareholder
- Support the user as they using the application in their personal and business.

Lehman’s law of Software Engineering.

the Laws of Software Engineering a series of laws that Lehman and Belady formulated starting in 1974 with respect to Software evolution. The laws describe a balance between forces driving new developments on one hand, and forces that slow down progress on the other hand.

'Re-engineering' is a set of activities that are carried out to re-structure a legacy system to a new system with better functionalities and conform to the hardware and software quality constraint. Reengineering may begin with a Business Process Reengineering (BPR) before move on to software reengineering.

General reengineering principles

1. Inspect the product

2. Inspect the structure of the product, rebuild if it is weak, remodel if it is structurally sound

3. Understand how well the original was built before you rebuild

4. If you begin rebuild, use only the best methods, tools, resources etc

5. Be disciplined about it – use practices that will result in high quality

Inventory analysis

An inventory list that contain information that provide description for example:-

– name of the application

– year it was originally created

– number of substantive changes made to it

– total effort applied to make these changes

– date of last substantive change

– effort applied to make the last change

– system(s) in which it resides

– applications to which it interfaces

Document restructuring.

1. Creating documentation is far too time consuming. If the system works, we’ll live with what we have. In some cases, this is the correct approach.
2. Documentation must be updated, but we have limited resources. We’ll use a “document when touched” approach. It may not be necessary to fully redocument an application.
3. The system is business critical and must be fully redocumented. Even in this case, an intelligent approach is to reduce documentation to an essential minimum.

Reverse Engineering

• Recreate design and specification information from the source code

• The process of analyzing a program in an effort to create a representation of the program at higher level of abstraction than source code.

Code structuring & restructuring.

Code structuring.

• Source code is analyzed using a restructuring tool.

• Poorly design code segments are redesigned

• Violations of structured programming constructs are noted and code is then restructured (this can be done automatically)

• The resultant restructured code is reviewed and tested to ensure that no anomalies have been introduced

• Internal code documentation is updated

Code restructuring.

• Activities:

1. Interpreting the source code and representing it internally

2. Simplifying the internal representation

3. Regenerating structured code

Data restructuring.

• Data restructuring is a full scale reengineering activity. In most cases, data restructuring begins with a reverse engineering activity.

o Current data architecture is dissected and necessary data models are defined (Chapter 9).

o Data objects and attributes are identified, and existing data structures are reviewed for quality.

o When data structure is weak, the data are reengineered.

• Because data architecture has a strong influence on program architecture and the algorithms that populate it, changes to the data will invariably result in either architectural or code-level changes.

Forward engineering.

• Forward engineering process applies software engineering principles, concepts, and methods to re-create an existing application.

• In most cases, forward engineering does not simply create a modern equivalent of an older program.

• Rather, new user and technology requirements are integrated into the reengineering effort.

• Capabilities of the older program may be extended too