Planning strategically, designing architecturally : a framework for digital library services

In an era of unprecedented technological innovation and evolving user expectations and information seeking behaviour, we are arguably now an online society, with digital services increasingly common and increasingly preferred. As a trusted information provider, libraries are in an advantageous position to respond, but this requires integrated strategic and enterprise architecture planning, for information technology (IT) has evolved from a support role to a strategic role, providing the core management systems, communication networks, and delivery channels of the modern library. Further, IT components do not function in isolation from one another, but are interdependent elements of distributed and multidimensional systems encompassing people, processes, and technologies, which must consider social, economic, legal, organisational, and ergonomic requirements and relationships, as well as being logically sound from a technical perspective. Strategic planning provides direction, while enterprise architecture strategically aligns and holistically integrates business and information system architectures. While challenging, such integrated planning should be regarded as an opportunity for the library to evolve as an enterprise in the digital age, or at minimum, to simply keep pace with societal change and alternative service providers. Without strategy, a library risks being directed by outside forces with independent motivations and inadequate understanding of its broader societal role. Without enterprise architecture, it risks technological disparity, redundancy, and obsolescence. Adopting an interdisciplinary approach, this conceptual paper provides an integrated framework for strategic and architectural planning of digital library services. The concept of the library as an enterprise is also introduced

EVALUATION OF CAPTURING ARCHITECTURALLY SIGNIFICANT REQUIREMENTS METHODS

Every software development organization strives for customer satisfaction. It is universally accepted that the success of software development lies in the clear understanding of the client requirements. During requirement elicitation and analysis stage, the system analyst identifies the functional and non-functional requirements from the customer. Security, usability, reliability, performance, scalability and supportability are the significant quality attributes of a software system. These quality attributes are also referred as non-functional requirements. Only a few functional and quality attributes requirement help to identify and shape the software architecture. A software system's architecture is the set of prime design decisions made about the system. If the requirement influences the architectural design decision then, it is referred as Architecturally Significant Requirement (ASR). Identifying and specifying all the possible ASR are important tasks in the requirement elicitation and analysis stage.In this research, general problems that are faced while capturing and specifying ASR in requirement elicitation and analysis is studied. Among the different requirement elicitation techniques, use case diagram has been identified and enhanced to solve the problem of capturing and specifying ASR during the requirement elicitation and analysis phase Â&nbsp

Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

Walley School Community Arts Center Feasibility Study: Appendices

Having a large capacity (over 300 seats) in Walley School demands a major investment in space and cost. Taking this into consideration, the business planning team conducted research and spoke with several individuals in an attempt to inventory and assess the community’s auditorium capabilities. Our research on existing auditorium spaces uncovered many interesting things. We found that there are over 15 existing auditorium spaces available within a 17-mile radius from the Walley School building available for public use

Barriers for façade integration of solar technologies

Solar energy has been actively promoted as a clean energy source for a long time; however, solar technologies have not been widely used in the built environment, mostly limiting their operation to industrial and macroscale applications. Along with commercially available products such as building integrated PV panels (BIPV) or building integrated solar thermal collectors (BIST); novel solar cooling integrated facades are seen as interesting alternatives for the development of new active façade components for high-performing commercial buildings. Nevertheless, there are barriers to overcome to push for widespread application of architecturally integrated solar façades. This chapter identifies perceived barriers for widespread façade integration of solar technologies, to explore the current scenario and generate guidelines for future developments. To achieve this, the chapter discusses the results of the second part of the survey presented in the previous chapter, which addresses the perceived potential and specific issues for the integration of solar technologies. General results point to economic aspects as the main barrier to overcome, followed by particular issues related to current limitations of components and architectural products. In this aspect, most mentions point to performance, aesthetics and technical complexity of current systems as issues to improve in order to promote the development of solar integrated architectural products

On Making Architecturally Significant Decisions in Agile Development : Case Study

Päätöksenteko on tärkeä osa ohjelmistokehitystä erityisesti kun kyse on ohjelmistoarkkitehtuurista. Ohjelmistoarkkitehtuuri voidaan jopa ajatella joukkona arkkitehtuurisia päätöksiä. Päätöksenteko vaikuttaa siis hyvin paljon siihen millaiseksi ohjelmistoarkkitehtuuri muodostuu. Tämä tutkielma tutkii arkkitehtuurista päätöksentoa ohjelmistokehitysprojektiin liittyen. Tämä tutkielma esittää tapaustutkimuksen tulokset, joiden pääasiallisena lähteenä on ollut haastattelut. Tapaustutkimuksen tapaus on yksittäinen tapaus, joka tehtiin alihankitun ohjelmistokehitysprojektin aikana. Päätökseen liittyy ohjelmistokehitystiimi ja useita sidosryhmiä asiakkaan puolelta, mukaanlukien arkkitehtejä. Ohjelmistokehitystiimi reagoi nopeasti päätöksen tarpeellisuuteen kun tarve nousi esille projektin aikana. Suurin osa päätöksentekoon liittyvästä työstä tehtiin ketterän ohjelmistokehityksen lomassa sujuvasti. Vain lopullinen päätös asiakkaalta tapahtui erillään ohjelmistokehitysprosessista. Tämä viimeinen hyväksyntä annettiin vasta jälkeenpäin, kun päätös oli jo käytännössä päätetty ja implementoitu. Tämä kuvaa hyvin kuinka vaikeaa on yhdistää ohjelmistokehityksen ulkopuolista päätöksentekoa ohjelmistokehitysprosessiin tehokkaasti. Tämän tutkimuksen tapauksessa päätöksenteossa oli työnjako, jossa yksi henkilö tutki ja valmisteli päätöksen. Tämän henkilön työ muodosti suurimman osan tehdystä työstä päätökseen liittyen. Tämän tyyppinen työnjako voisi mahdollisesti olla yleistettävissä päätöksentekoon yleisesti ohjelmistokehityksen piirissä.Decision-making is an important part of all of software development. This is especially true in the context of software architecture. Software architecture can even be thought of as a set of architectural decisions. Decision-making therefore plays a large part in influencing the architecture of a system. This thesis studies architecturally significant decision-making in the context of a software development project. This thesis presents the results of a case study where the primary source of data was interviews. The case is a single decision made in the middle of a subcontracted project. It involves the development team and several stakeholders from the client, including architects. The decision was handled quickly by the development team when an acute need for a decision arose. The work relating to the decision-making was mostly done within the agile development process used by the development team. Only the final approval from the client was done outside the development process. This final approval was given after the decision was already decided in practise and an implementation based on it was built. This illustrates how difficult it is to incorporate outside decision-making into software development. The decision-making also had a division of labour where one person did the researching and preparing of the the decision. This constituted most of the work done relating to the decision. This type of division of labour may perhaps be generalized further into other decision-making elsewhere within software development generally