************ Business Modeling [ERIKSON-2008] *****************************************************

A model is a simplified view of a complex reality. It is a means to creating abstraction, allowing you to eliminate irrelevant details and focus on one or more important aspects at a time. An actor is a role that a user or another system has. The objective of use case modeling is to identify and describe all the use cases that the actors require from the system. Reasons for doing business modeling:

To better understand the key mechanisms of an existing business.

To act as the basis for creating suitable information systems that support the business.

To act as the basis for improving the current business structure and operation.

To show the structure of an innovated business. The model becomes the basis for the action plan.

To experiment with a new business concept, or to copy or study a concept used by a competitive company (ex. Benchmarking on the model level).

To identify outsourcing opportunities. Business modeling with UML, New concepts:

Stereotypes > Allows to create new building blocks from existing ones but specific to your problem.

Tagged values (properties) > Allows to create new information in that element’s specification.

Constraints > Allows to add new rules or modify existing ones. The primary concepts used when defining the business system are:

Resources

Processes

Goals

Rules Activity Diagrams are used to document program flow, to show the algorithm used to implement a specific operation.

Business process: a process is a specific ordering of work activities across time and place, with a beginning, an end and clearly identified inputs and outputs: a structure for action. In simple terms can be described as a number of activities. Resources that are used or needed by the process have their dependency stereotyped to “supply” and a resource that controls the process has its dependency stereotyped to “control”. A complete business model is shown is a number of views. Each view is expressed in one or more diagrams. Diagrams capture the processes, rules, goals, and objects in the business, and their relationships and interactions with each other. The Eriksson-penker Business Extensions use 4 different views of a business:

Business Vision View: Overall vision of the business, describes a goal structure for the company and illustrates problems that must be solved in order to reach those goals.

Business process view: represents activities and value created in the business. Illustrates the interaction between processes and resources in order to achieve the goal of each process, as well as interaction with different processes.

Business structural view: Structures among the resources of the business, such as organization of the business or the structure of the products created.

Business behavioral view: individual behavior of each important resource and process in the business model and how they interact with each other.

The business model is used in software modeling to:

Identify the information system that best support the operation of the business.

Find functional requirements

Find non-functional requirements

Act as a basis for analysis and design of the system

Identify suitable components

************ Peer Reviews/ Code Reviews [SMARTBEAR-2009] ******************************************

Peer code Review is practice where software developers review each other’s code before releasing software to QA. It is important because it identifies bugs, encourages collaboration, and keeps code more maintainable. 11 Best practices for efficient, lightweight peer code review:

1. Review fewer than 200-400 lines of code at a time 2. Aim for inspection rate of less than 300-500 LOC/hour

important definitions > Inspection rate: how fast able to review code. kLOC thousand lines of code per man -hour > Defect rate: how fast able to find defects. Measured in number of defects found per man-hour. > Defect density: hoy many defects find in a given amount of code, measured in number of defects found per kLOC.

3. Take enough time for a proper, slow review, but not more than 60-90 min. 4. Authors should annotate source code before the review begins. (not comments in code, but rather comments

given to other reviewers) 5. Establish quantifiable goals for code review and capture metrics so you can improve your processes. (most

common internal metrics for code are inspection rate, defect rate, defect density) 6. Checklists substantially improve results for both authors and reviewers.

Reminds authors and reviewers to > confirm all errors are handled > function arguments are tested for invalid values > unit tests have been created

7. Verify that defects are actually fixed 8. Managers must foster a good code review culture in which finding defects is viewed positively. 9. Beware of the Big Brother effect. Metrics should never be used to single out devs, particularly in front of their

peers. This practice can seriously damage morale. 10. The ego effect: do at least some code review, even if you don’t have time to review at all. 11. Lightweight style code reviews are efficient, practical and effective at finding bugs.

************ [METHODS-TOOLS-2002] Page 7 – 20 ***************************************************

There are 2 different approaches to remove defects from programs. Reactive one: the program is finished, let’s test it to see if it works. Proactive one: The program is finished, let me see if it is a good one. Software inspections or reviews are an old concept that is based on the fact that four eyes are better than two. Benefits: fewer errors, more readable code, emulation between devs, backup of system knowledge and sharing of software development ideas. To build effective products, you need to focus on hard stuff. Be it project managers, methodology, tools, supportive processes or even deploying a Project Management Office (PMO) one need to understand how strategy plays such an important part within their respective organization. It’s crucial for any project manager to address the larger issues of the business strategy and see where the project fits in the overall framework. Organization must master project management as a method in order to be successful in the marketplace. A PMO is another key business strategy used by companies to manage their projects, in order to maximize their value to the organization. Projects need to bring in solutions faster, cheaper or with a cost advantage, which is unique, focused and be able to serve clients worldwide.

Businesses clearly have to:

Either eliminate or minimize their competitors.

Achieve new advantages that increase or improve customer satisfaction, which differentiate them from their competitors.

Achieve speed to market.

Re-engineer business processes for improved competitiveness.

Align their organizations to the latest economic trends.

Implement the strategy (i.e. through projects).

Evaluate the success of the strategy (i.e. measure project success). IT departments therefore need to:

Re-examine their current project management practice.

Determine current strategies.

Identify bottlenecks.

Be able to act on existing projects. IT projects need to be managed centrally. By providing solid, repeatable strategies, which serve as the foundation for nay successful project initiative, supported by:

1. Well-documented goals and visions. 2. Repeatable best practices. 3. Consistent results.

Software Inspections: Inspections to find defects earlier and at a lower cost. The objective of inspections is to reduce the cost of quality by finding and removing defects earlier and at a lower cost. Inspections have clear value independent of any model or standard for software development. Effectiveness of inspections is the percentage of defects removed by inspections compared to the total sum of defects eventually found by inspections, test and in use by the customers. Efficiency of inspections is represented by various cost relationships:

Money spent / defect found in inspections Money for inspections / total project costs Money ratio of cost of finding defects in Inspection to cost of defects found in test and by the customers Hours spent / defect found in inspections

Use Inspections to find defects earlier because the costs for defect removal are reduced, then this is a measure of the efficiency. Defects are a cost driver to a project; i.e., the more defects the higher the cost to remove them. Therefore, the lower the cost to remove defects the more efficient we are. 1:1 Inspections occur when there are only two participants in an Inspection, the Producer and the Inspector/Moderator. When an Inspection finds too many defects, this is a signal to management to do a better job of managing the software processes and people resources.

Solo: Inspections the inspector logs on to his workstation and brings up the work product to be inspected. He has all required documents available through the organization’s intranet for ancillary and reference documents he may need. He has access to the appropriate checklist, standards, and forms to record any defects found. He can open as many concurrent windows or views with required documents as he needs to perform the Inspection. His time is recorded based on log-on time. When he is done, he submits his Inspection documents to the Producer, Inspection Coordinator, and Project Lead. He is then available to the Producer if there should be any questions. An advantage is that in Solo: Inspections the inspector makes a commitment to the Project Lead for a completion time or date and this is what he then can concurrently manage along with other work in his queue. Another advantage is that the Producer and inspector can be in two different locations.

Weller [WEL93] states that there are disadvantages of inspecting after unit test:

• Unit test leads programmers to have false confidence that the product works, so why inspect

• It is a hard decision to inspect a large batch that has been unit tested and there may be the view that there is no longer

time to inspect

He also gives reasons to perform Inspections first:

• You may actually be able to bypass unit test if the Inspection results are good

• You can recover earlier with lower cost to serious design defects found in Inspections versus unit test