Software development is a complex task. Abstraction is one means used for reducing the complexity involved in software product development. One way by which abstraction is expressed is by removing details in order to simplify and capture a concept, finding a common denominator for generalization. Though abstraction is a useful tool, it is not always used; sometimes it is just difficult to think abstractly, and sometimes abstraction is not utilized due to a lack of awareness of its significance and its potential contribution. Abstraction Levels in Agile Software Development: Abstract thinking is needed in software engineering in order to understand the requirements and simplify the product design, keeping it maintainable and ready for ongoing changes.

1. Abstraction
By, P.Shanmugapriya

2. • Software development is a complex task.
• Abstraction is one means used for reducing the complexity involved in software product development.
• One way by which abstraction is expressed is by removing details in order to simplify and capture a concept,
finding a common denominator for generalization.
• Though abstraction is a useful tool, it is not always used; sometimes it is just difficult to think abstractly, and
sometimes abstraction is not utilized due to a lack of awareness of its significance and its potential
contribution.
• Abstraction Levels in Agile Software Development:
• Abstract thinking is needed in software engineering in order to understand the requirements and simplify the
product design, keeping it maintainable and ready for ongoing changes.
• Roles in Agile Teams
• Teamwork, can be viewed as a means that encourages software developers to look, think, and examine the
development process on different abstraction levels.
• More specifically, if a team member wishes to perform the personal role successfully, that is, to lead the
project in the direction that the role specifies, he or she must gain a more global and abstract view of the
developed application as well as of the development process.

3. • For an illustration, we examine the tracker role.
• The tracker collects data according to a set of measures used by the team, e.g., the actual development time
of specific tasks.
• The minimal set of measures usually includes information about the project’s progress relative to previous
estimations and a measure that deals with the product quality for example, code coverage .
• While the data is being collected, the tracker communicates with the other teammates.
• The tracker also analyzes and presents the measures at every iteration.
• This analysis is carried out at a higher level of abstraction than that needed for the actual data gathering.
• The former examines the project from a global view; the latter delves into the details of specific tasks.
• Abstraction During Iteration Planning:
• The concept of short releases/iterations, and the planning sessions that direct the development process,
encourage all the project stakeholders to move between levels of abstraction and to improve their
understanding of the developed software gradually and periodically.
• While the release planning sessions inspire a global view of the developed product at a higher abstraction
level, planning is conducted on a lower level of abstraction in the iteration planning sessions, considering the
development tasks for the next iteration and their time estimation.

5. • The Stand-Up Meeting:
• The stand-up meeting is conducted at the beginning of every development day.
• It takes about ten minutes, in which each teammate describes in up to one minute what he or she
accomplished the day before with respect to project development, what he or she is going to perform today,
and the main problems encountered, if any.
• The meeting goal is to share relevant infor- mation about the project and to launch the development day.
• The coach who listens to the main problems can take care of them briefly during the stand-up meeting or, if
needed, during the development day. The teammates stand during the meeting to make it short and concise.
• Design and Refactoring
• Software design is carried out on a higher level of abstraction than code development.
• In other words, the development of a specific part of the software includes details which are eliminated when
the design is constructed.
• Design is used to simplify communication with respect to the software and to represent the structure of the
software components in an organized manner that can be und stood by the different developers involved.
• Design can be sketched by some visual model and should be kept simple and clear.
• Refactoring or redesign means that we improve the software design without adding functionality.
• Refactoring is based on the current design and it attempts to simplify it and ease future changes.

6. • This activity requires thinking at a higher abstraction level than the level of abstraction needed when dealing
with the design itself.
• Reaching a simple design is not a simple task, and therefore refactoring is one of the practices that people find
hard to accomplish.
• This difficulty can be explained by the need to think about the code at a higher level of abstraction than the
level of abstraction on which the code was written.
• Since the practice of refactoring encourages programmers to keep improving code structure and readability
without adding functionality to the code, the essence of refactoring is a gradual process of code improvement.
• Further, in practice, when a need for an extensive refactoring is acknowledged and is agreed to by the
customer in the planning session, time is allocated for refactoring, and the same activities conducted with
respect to code development, such as breaking down the refactoring activity into small parts and time estima
tion, are conducted with respect to code refactoring.
• Ongoing refactoring takes time. The return on this investment, however, is expressed in maintenance activities,
in which changes are inserted in clear and easy-to-change code.

7. • Abstraction in Learning Environments:
• During this meeting, the planning session is completed by preparing a list of tasks that are split among the
teammates according to their available time during this iteration. Load balance is also performed.
• If the academic coach concludes that the team can perform the entire planning session on their own, as a
self-organized team, he or she can leave the studio and let the team complete the planning session and
publish the results|a list of personal task ownerships|in the electronic forum.
• At the end of this meeting, the second iteration of the product development starts.
• Teaching and Learning Principles
• Be Aware of Abstraction Levels:
• During the process of software development, teammates are required to think at different abstraction levels
and to move between abstraction levels.
• Accordingly, this teaching principle suggests that the instructor and the academic coach should be aware of
the abstraction level at which each stage of each lesson/activity is performed.
• Based on this awareness, they should then decide whether to stay at this abstraction level, or, alternatively,
whether there is a need to guide the learners to think in terms of a different level of abstraction.
• The iteration-based course structure supports this principle. It allows the learning community to start, in the
first stages of the course, with a more specific examination of the main course ideas, and to proceed to a
more abstract perspective in the later stages, based on the understanding gained in the earlier stages.

8. • Refactoring Activity:
• This case study describes a refactoring activity facilitated with 32 students who developed software products
as part of two project-based courses taught in two different academic institutions.
• The academic coaches of both courses attended the activity session.
• The subject was refactoring and the goal was to increase the students’ awareness of abstraction as well as
their abstraction skills.
• The hands-on section is based on three worksheets.
• The first worksheet defines the practice of refactoring and its goals, and, based on that definition, asks the
students to suggest examples of refactoring operations.